App development: where the money actually goes

Where the money actually goes

People assume they are paying for code. Mostly they are paying for decisions, and for the cost of changing decisions late.

A rough split on a typical project: discovery and scoping, design and user flows, build, testing, and then the part nobody budgets for, which is everything after launch. Maintenance, updates, platform changes, and the features you did not know you needed until real people used the thing.

That last category is not a footnote. Software is not a purchase, it is a commitment. Any quote that ends at launch has quietly handed you an ongoing cost and called it done.

Why estimates blow out

• The brief was a wish list, not a scope. "It should also do X" is the most expensive sentence in software, and it always arrives in week six.
• Nobody defined done. Without a hard definition, the project expands to fill the budget and then some.
• Edge cases were treated as details. They are not details. They are most of the work.
• Integrations were assumed to be simple. They are never simple. The other system was not built for you.
• The first version tried to be the final version. This is the big one.

The defense against all five is phasing. Build the smallest thing that solves the actual problem, put it in front of real users, and let what you learn shape phase two. It feels slower. It is dramatically cheaper.

Do you actually need an app?

Genuinely ask. A lot of "we need an app" conversations end, correctly, with a website, a spreadsheet, or an automation.

• If it is a marketing problem, build a [website](/services/web-design). Nobody is downloading an app to look at your services.
• If it is a repetitive internal task, automate it. Cheaper by an order of magnitude, and live in weeks.
• If it needs to be found on Google, it is a web thing. App stores are not search engines for your business.
• If you need it on someone's phone, in their pocket, used regularly, then yes, build the app.

Here is the version we say out loud, because it costs us work: if a task can be automated, automate it before you throw more people, or more software, at it. We have watched teams copy-paste leads between forms, spreadsheets and a CRM by hand and conclude they needed a custom platform. They needed an agent handling the hand-off, which took a fraction of the time and money.

How to scope so it does not run away

1. 1Write the problem, not the solution. "Our techs waste 40 minutes a day on job sheets" beats "we need a mobile app with offline sync".
2. 2Define phase one as the smallest useful thing. Ruthlessly. If it feels embarrassing, it is probably right.
3. 3Name what is explicitly out of scope. In writing. This one sentence saves projects.
4. 4Budget for after launch. A rule of thumb is that the first year of running it is a meaningful fraction of building it.
5. 5Agree how you will know it worked. A number. Before you start.

That is how our app and software work is structured, scoped carefully, built in phases, with the uncomfortable conversation about whether you need it at all happening before the invoice rather than after.

The costs nobody puts in the quote

The quote covers the build. The business case has to cover everything else, and "everything else" is where app projects turn into regrets.

• Maintenance. Operating systems change, dependencies age, security patches arrive. An app that nobody maintains stops working, not dramatically, just gradually, until one day it does not launch.
• Platform changes. Apple and Google update requirements on their schedule, not yours. Compliance work is not optional and it is not free.
• Support. Real users ask real questions. Someone has to answer them.
• The features you did not know you needed. These only appear once people actually use the thing, and they are usually the ones that determine whether it succeeds.
• Hosting, monitoring, and the boring infrastructure that everyone forgets until the bill arrives.

A reasonable rule of thumb: the first year of running an app is a meaningful fraction of the cost of building it. Anyone who quotes you a build cost and goes quiet about year two is not being dishonest, exactly, but they are letting you assume something that is not true.

Which is why the question "do we actually need this?" deserves a serious hearing before anyone writes code. If the same outcome is available by automating a workflow or fixing the website, take it. The cheapest software project is still the one you talked yourself out of.

Early signs a build is going wrong

Software projects rarely fail on a single dramatic day. They drift, and by the time it is obvious, a lot of money has been spent. These are the early signals.

• Nobody can demo anything after six weeks. Working software beats status reports. If there is nothing to click, ask why.
• The scope keeps quietly growing. Each addition sounds small. Together they are the project.
• Integrations keep slipping. The other system was not built with you in mind, and integration is where optimizm goes to die.
• Nobody has used it but the developers. Real users find in an hour what a team misses in a month.
• "We will fix that in phase two." Sometimes true. Often a way of not deciding.

The best protection is a short feedback loop. Something working, in front of a real person, early, even if it is ugly and does only one thing. That single discipline catches nearly every problem on the list above while it is still cheap to fix.

And if the app is going to have a public-facing side, hold it to the same standard as any website: it needs to be fast, and it needs to be usable. Core Web Vitals apply just as much to a web app as to a marketing page, and accessibility standards are not an optional extra you bolt on at the end. Retrofitting either one is far more expensive than building with them in mind.

Frequently asked questions