# Build a backend or API > A backend or API is the part of a product people do not see: it stores data, checks who may do what and talks to other services. To build one, you describe the data and the actions first, then agree on how the API is documented and tested. ErdiBuilds is an open marketplace where clients post app, SaaS, website and game projects, see which independent developers from the EU fit best based on what they have already built, and pay per milestone. Canonical: https://erdibuilds.app/build/backend-api Last updated: 2026-11-06 (November 6, 2026) ## When you need a backend on its own Sometimes the screens exist already and the engine is missing. Maybe a designer or a no-code tool built the front end, a mobile app needs a server, a partner wants to connect to your data or an old system must be replaced. An API (A set of rules and addresses that lets one program ask another for data or actions.) is how the front end and other programs use the backend. Typical work includes user accounts, a database design, payment and email connections, imports, scheduled jobs, webhooks and an admin interface. If you also need the screens, look at [web app](https://erdibuilds.app/build/web-app) and [mobile app](https://erdibuilds.app/build/mobile-app) projects. ## Typical technologies Many choices work. What matters is that your developer knows the one they pick and that you can find other people who know it. [Find My Stack](https://findmystack.app/?project_type=backend-api) can help you compare. - Languages and runtimes such as [Node.js](https://erdibuilds.app/hire/nodejs) with TypeScript (JavaScript with types, which catches many mistakes before the code runs.) or [Python](https://erdibuilds.app/hire/python). - Postgres (A widely used open source relational database.) for structured data, often through [Supabase](https://erdibuilds.app/hire/supabase) with login, storage and Row Level Security (A database feature that decides row by row which user may read or change which data.) built in, or [Firebase](https://erdibuilds.app/hire/firebase) as a different style of backend. - REST (A common style of API where each kind of data has its own address and standard actions like read, create and delete.) or GraphQL (A query language for APIs where the client asks for exactly the fields it needs.) for the interface. - Webhooks (Messages that another service sends to your app when something happens, such as a payment succeeding.) and [Stripe](https://erdibuilds.app/hire/stripe) for payments, plus queues for tasks that run later. - An OpenAPI document (A machine readable description of every address, input and output of an API, used for documentation and test tools.) so every consumer of the API knows how it behaves. ## An example plan in milestones Because there is little to see, make every milestone checkable with tools or test calls. Each milestone is funded before work starts and runs 1, 2, 3, 4, 6 or 8 weeks. Milestones are from 50 to 2,000 each in your project currency. 1. For example, weeks 1 to 2, design: data model, list of endpoints, permission rules and an API description you can read. Check it against your use cases. 2. For example, weeks 3 to 5, core endpoints: login, the main data, validation and errors. Check with a request tool and a test report. 3. For example, weeks 6 to 7, integrations: payments, email, third party services, webhooks, background jobs. 4. For example, weeks 8 to 9, hardening: rate limits, logging, backups, load test of the busiest endpoint, security review of permissions. 5. For example, week 10, handover: deployment steps, environment variables, documentation and a walkthrough. The weeks are for illustration. Developers set the length of each milestone in their proposal, and each real milestone runs 1, 2, 3, 4, 6 or 8 weeks. Splitting by feature works better than splitting by layer. See [how to split a project into milestones](https://erdibuilds.app/guides/how-to-split-a-project-into-milestones). ## What belongs in the project description - Who or what will call the API: your own app, partners, other systems. - The main things it manages, for example customers, orders and files, with the fields you know. - Who may do what, in a simple table of roles and actions. - Existing systems, databases or spreadsheets to import from or connect to. - Expected traffic in plain words, such as a few hundred users a day or bursts at a certain hour. - Where it should run, and any rules about where data must be stored. - Documentation you expect: API description, setup guide, tests. ## How to recognise a suitable developer Good backend developers talk about data and rules before tools. Ask how they test, how they handle errors, how secrets such as API keys (Secret codes that prove a program may use a service. They must never be placed in public code.) are stored and how they would let you switch developers later. Open source work or a repository walkthrough shows habits better than a list of skills. The match score (A number from 0 to 100 that shows how well a developer fits your project, with plain reasons such as shared technologies, similar past work, budget fit and availability.) on each proposal gives you a first sort. A developer needs at least 40 to apply, and 80 or more gets a Top match badge. Check the Expert in list, which holds up to 6 technologies. Developers are independent professionals, not our employees. ## Frequently asked questions ### Can I hire a developer for a backend without screens? Yes. Milestones are then checked with documentation, test calls and a test report instead of screens. Make sure the criteria are written into each milestone. ### Can a backend work with my no-code front end? Often, yes, if the front end can call an API. Check this before you decide, and ask your developer to test one real call early. ### What documentation should I ask for? An API description, a setup guide for running the project, a list of environment variables and notes on how to deploy. Without these, switching developers gets hard. ### How is the backend kept secure? Through permission checks on every action, safe storage of secrets, input checks and logging. Ask for a short security checklist in the hardening milestone. ### Who owns the code? Unless both sides agree otherwise in writing on the platform, the rights to the result of a milestone pass to the client once that milestone is paid in full. Use your own accounts for hosting and the database, and store code in a repository you control. ## Related - [Build a web app with an independent developer](https://erdibuilds.app/build/web-app): How to plan a browser-based web app: common technologies, an example milestone plan, what to write in the brief and how to judge a developer. - [Build a mobile app with a developer](https://erdibuilds.app/build/mobile-app): Plan an iPhone and Android app: typical technologies, an example milestone plan, what to put in the brief and how to spot a developer who fits. - [Hire a Node.js developer for your server](https://erdibuilds.app/hire/nodejs): Node.js runs the server side of apps and APIs. Learn what a Node.js developer builds, what to ask and how milestones and matching work. - [Hire a Supabase developer for your backend](https://erdibuilds.app/hire/supabase): Supabase stores data and handles logins for apps. Learn what a Supabase developer does, what to ask, and how projects and matching work. - [Who Owns the Code When You Hire a Developer?](https://erdibuilds.app/guides/who-owns-the-code): Learn who owns the code, design and data when a freelancer builds your software, what usually stays with the developer, and how to agree on it in writing. - [Take Over an Existing Codebase Safely](https://erdibuilds.app/help/take-over-an-existing-codebase): Moving code from another developer or agency? Use this handover checklist for access, documents and a first audit milestone.