Why one number is the wrong first question
Ask five studios what a web app costs and you will get five answers that are hard to compare. That is rarely dishonesty. It is because “web app” covers everything from a login screen over a spreadsheet to a multi-tenant platform with payments, permissions and real-time updates, and each studio quietly fills the gaps in your brief with its own assumptions.
The useful question is not “how much?” but “which decisions move the price, and which of them have I already made?” Once you can answer that, quotes start to line up, and you can see where one studio has included something another has left out.
The decisions that actually move the price
Screens are the thing people count, but screens are rarely what makes a build expensive. The cost lives underneath them. In our experience these are the drivers worth pinning down before you ask for a quote:
- User roles. Every role (customer, staff, admin, partner) needs its own permissions, its own views and its own tests. Two roles is a different project from six.
- The data model. How many kinds of record exist, how they relate, and who is allowed to see which ones. This is where most of the hidden engineering sits.
- Integrations. Each outside service (payments, email, CRM, a broker or shipping API) brings authentication, webhooks, failure handling and a sandbox to test against.
- Money. Taking payments, running subscriptions, issuing refunds and handling failed cards is a small product of its own.
- Real-time behaviour. Live chat, notifications and presence need infrastructure that a request-and-response app does not.
- Compliance and security. Handling health, financial or children's data changes how you store, log and audit everything.
- Design depth. A bespoke design system with every state drawn is more work up front than adapting a component library, and it usually pays that back later.
Roles and permissions deserve a closer look
Permissions are the driver founders most often underestimate. When we built Forjwell One, our own client portal, the team board and the client portal share the same records, but a client may only see work that has been explicitly shared with them. Getting that rule right on every list, search result, notification and file link was a significant part of the build, far more than drawing the screens.
If your product has more than one kind of user, write down in plain language what each one can see and do. That single page will improve every estimate you receive.
What usually gets left out of the first quote
The features you describe are rarely the whole job. These are the pieces that tend to appear later as change requests, so it is worth asking about them directly:
- An admin area so your team can fix a customer's account without calling a developer.
- Empty, loading and error states for every screen, not only the happy path.
- Transactional email and notifications, including the copy.
- Importing data from whatever you use today.
- Testing across the browsers and devices your users actually have.
- Hosting, monitoring, backups and a plan for who responds when something breaks.
How to get an estimate you can hold someone to
A trustworthy quote is written, specific and phased. It should say what is in scope, what is explicitly out, what each phase delivers and what it costs, and how changes are priced once work starts. It should also say who owns the code and the design files at the end. With us the answer is you.
Phasing matters more than the headline figure. Verus, a trader-verification platform we designed and built, agreed its scope and integrations in a statement of work before any design started, and the build landed in milestone releases. Each milestone could be reviewed on its own, which kept the budget and the roadmap honest from one month to the next.
Be wary of a single fixed number for a large, loosely defined product. Either the studio has padded it heavily to cover the unknowns, or it will be renegotiated later. A fixed price per phase, with the next phase re-estimated once you have seen the last one, is fairer to both sides.
Time and money move together
Asking for the same scope in half the time rarely halves the cost. Past a point, adding people to a build adds coordination faster than it adds progress, and rushed work tends to come back as bugs after launch. If the date is fixed, the scope is what should flex.
The cheapest timeline is usually the one where decisions arrive quickly. A founder who can review a design within a day and answer product questions the same week saves more money than any discount on the hourly rate. When you compare quotes, ask each studio what it needs from you, and how often, to hit its dates.
Ways to spend less without building worse
Most savings come from saying no to things, not from cheaper hours. The reliable ones:
- Launch on the web first. A progressive web app can be installed on a phone and avoids building and maintaining two native apps before you know people want the product.
- Use managed services for solved problems: authentication, payments, file storage and email. Build only what makes your product different.
- Cut roles from version one. Run the rare admin tasks by hand until the volume justifies software.
- Agree the design system early, so every new screen is assembly rather than invention.
- Keep a written list of “later” features, so saying no today does not feel like saying never.
Where our own pricing starts
We publish our starting points rather than hide them. A defined project build starts from $6,000, a monthly retainer for ongoing work starts from $1,500 a month, and larger platforms are scoped and quoted in phases. The engagement models page explains what each one includes.
The honest answer to “how much will my app cost?” is still “it depends”, but it should depend on decisions you can see and control. After a free strategy call we send a written roadmap with each phase costed, so you know what you are paying for before anything starts.
