Build a web app with an independent developer

What a web app is, and what people build with it

A web app is more than a website. People log in, create things, change data and see results that depend on who they are. There is nothing to install, no store review and an update goes live as soon as it is deployed.

Typical projects are client portals, booking and scheduling systems, dashboards on top of existing data, community platforms, small marketplaces and online tools for one specific job. If people pay a subscription, read about building a SaaS. If only your team uses it, see internal tools. If the pages mainly present content, a website is the simpler path.

Typical technologies

Most web apps today have a front end that people see and a back end that stores data and checks permissions. Find My Stack suggests combinations based on your goals.

• Next.jsi and plain Reacti are the most common front end choices.
• TypeScripti makes the code easier to change later.
• Postgresi stores structured data. Supabasei bundles it with login and files.
• Row Level Securityi keeps one customer from seeing another customer's data. Ask your developer how it is used.
• Stripei is common if users pay inside the app. Hosting on a platform such as Vercel keeps releases simple.
• For Python or Node.js back ends, see the pages on Node.js and Python developers.

An example plan in milestones

This sketch fits a small app with accounts and one main workflow. Milestones are from 50 to 2,000 each in your project currency. Each milestone is funded before work starts and runs 1, 2, 3, 4, 6 or 8 weeks.

1. For example, weeks 1 to 2, foundation: page layout, design system, sign up and login, database tables and permissions. You can create an account and see an empty dashboard.
2. For example, weeks 3 to 5, main workflow: the screens and logic for the core job, with real data saved. You can walk through the whole flow on a test version.
3. For example, weeks 6 to 7, polish and safety: validation, error messages, emails, loading states, basic monitoring and a check of who can see what.
4. For example, week 8, launch: production setup, your own domain, a short handover note and a list of known follow-ups.

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. Your developer may combine or split these steps. The milestone planner helps you test different splits.

What belongs in the project description

• Who uses the app and what they must be able to do in the first version.
• Different roles, for example visitor, member and admin, and what each may do.
• Data the app stores and where it comes from, including imports from spreadsheets or other tools.
• Integrations such as payments, email, calendars or an existing system.
• Design status: finished screens, a rough sketch or nothing yet.
• Rules about privacy or accessibility that apply to you.
• What you want to postpone to a second version.

How to recognise a suitable developer

Ask for a live app they built with accounts and data, not only a landing page. Check that they explain trade-offs in plain words and ask about your users before they pick tools. A short repository tour, with tests and a readable structure, is a good sign.

On ErdiBuilds, the match scorei sums up the fit. A developer needs 40 or more to apply, and 80 or more gets a Top match badge. Developers are independent professionals, not our employees. See also how to hire a developer safely.