Build a backend or API

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 APIi 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 and 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 can help you compare.

• Languages and runtimes such as Node.js with TypeScripti or Python.
• Postgresi for structured data, often through Supabase with login, storage and Row Level Securityi built in, or Firebase as a different style of backend.
• RESTi or GraphQLi for the interface.
• Webhooksi and Stripe for payments, plus queues for tasks that run later.
• An OpenAPI documenti 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.

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 keysi 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 scorei 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.