"How much for an app?" is a fair question with an unfair answer, because the honest response is another question: what are you replacing?
Software cost is not driven by screens. It is driven by rules, integrations, and how much of your current process is undocumented. Here is how the money actually splits on a typical build, and how to read a quote critically.
Where the budget goes
On most builds we have delivered, the rough split looks like this:
| Phase | Share of budget | What it buys |
|---|---|---|
| Discovery and process mapping | 10–15% | Writing down what your business actually does |
| Design and flows | 10–15% | Screens, states, error paths |
| Core build | 40–50% | The working software |
| Data migration | 5–15% | Getting your existing records in cleanly |
| Testing and fixes | 10–15% | Catching what discovery missed |
| Training and handover | 5–10% | Getting your team using it |
Notice that less than half the money is the part most people think of as "building the app". That is not padding. Skip discovery and you build the wrong thing. Skip migration and you launch an empty system nobody can use. Skip training and you have paid for shelfware.
Why quotes vary by 5x for "the same" app
Two vendors quote for the same brief and come back 400% apart. Usually one of these explains it.
One quote includes discovery and the other does not. The cheaper vendor will do discovery too — they will just bill it later as "change requests" once the vague brief meets reality.
One assumes clean data and the other has seen your spreadsheets. Migration cost scales with mess, not volume. Ten thousand tidy rows are cheaper than four hundred rows with three date formats, duplicate customers spelled four ways, and amounts stored as text.
One is quoting a template and the other a build. Both are legitimate. A configured template is faster and cheaper and constrains you to how the template thinks. Just make sure you know which you are buying.
One included the boring parts. Roles and permissions, audit trails, password resets, exports, offline handling, backups. None of these appear in a demo. All of them are required in production, and together they are frequently a third of the real work.
Questions that expose a thin quote
Ask these before signing anything:
- Which specific screens are in scope, and what is explicitly out?
- Who writes the data migration script, and how many test migrations are included?
- How many user roles, and what exactly can each one see and not see?
- What happens on a bad network — does it queue, fail, or lose data?
- Is the source code mine at the end, and where does it live?
- What does the second year cost, once the build is done?
That last one matters. Software has a running cost: hosting, monitoring, small fixes, changes when your process changes. Budget 15–25% of the build cost per year for it. Vendors who do not mention it are not cheaper; they are just deferring the conversation.
How to spend less without buying less
You can genuinely reduce cost, but not by squeezing the day rate. The levers that work:
Cut the scope, not the quality. One workflow built properly beats five built badly. Pick the process that costs you the most time or the most money today, and do only that in phase one.
Do your own data cleanup. If your team standardises the spreadsheet before handover, you can remove most of the migration line. This is real work, but it is work your staff can do and you would otherwise pay a developer to do.
Write down your rules first. Every hour a developer spends chasing "what happens if a customer pays half now and half later?" is a billed hour. An afternoon with your team and a document saves days.
Use standard components. A bespoke date picker costs money and is worse than the standard one. Save the custom design budget for the two or three screens your customers actually see.
What we would not cut
A few things are false economy:
- Testing. A bug found in testing costs an hour. The same bug found by your customer costs a customer.
- Backups and recovery. Cheap to set up, catastrophic to lack.
- Training. The gap between a system that is deployed and a system that is used is entirely training.
- Documentation of the data model. This is what lets a different developer take over later. Without it you are locked to one vendor forever.
Getting a number that means something
Come to a scoping conversation with three things and you will get a quote worth comparing: a description of the process you want replaced, a sample of the data you currently keep, and a list of who will use the system and what each of them should be allowed to do.
That is usually enough to price honestly. If you would like us to scope it with you, book a consultation — we will give you a range and tell you plainly which parts you could do without.