Guide · App development cost
What makes an app expensive,and what a demo tells you first.
The cost of an app is driven by what it has to connect to, protect and get right, not by how many screens it has. This guide explains which decisions actually move a quote, how to keep a first version affordable, what a free basic demo shows before you spend anything and when a written quote becomes possible.
Why the number of screens is the wrong measure
When people ask what an app costs, they usually count screens: a login, a list, a detail page, a settings page. Screens are the visible part, and they are the cheapest part. Drawing a form and showing a list of records is routine work, and AI-assisted development has made it faster still.
What takes time is everything behind the screens: where the data comes from, who is allowed to see it, what happens when a payment fails or two people change the same record at once. Two apps with the same ten screens can differ several times over in cost, because one reads sample data and the other talks to your accounting system, handles roles and takes money.
So when you compare quotes, compare what sits behind the screens, not how many there are.
What actually drives the cost of an app
Five things move a quote more than anything else. Integrations with other systems, because every external tool has its own interface, limits and ways of failing, and each connection has to be tested against real behaviour. User accounts and roles, because once different people see different things, every feature has to respect permissions. Payments and compliance, because taking money means refunds, receipts, disputes and the rules of your sector. Data migration, because moving years of spreadsheets or an old database into a new structure means cleaning up what was never consistent. And changes of scope, because a feature added halfway through often touches what was already built.
Business rules sit in between: easy to describe, but every exception you handle by hand today has to be written down and tested.
How to reduce the cost of an app
Most of the saving comes from deciding what the first version does not do. These choices cut cost without cutting quality:
- Start with one journey: the path a user takes most often, done completely, before anything else.
- Use sample data first, so the structure is right before real accounts and systems are connected.
- Reuse what you already pay for: an existing login, a payment provider, your accounting system’s export, instead of rebuilding them.
- Decide what stays manual: an exception that happens twice a month can be handled by a person, not by code.
- Write the scope down before work starts, so additions are visible decisions rather than surprises.
None of this makes the product smaller for good. It makes the first version something you can pay for, use and extend.
What a free basic demo tells you before you spend
A basic demo is one working piece of the idea: one screen, one page or one automated step, with sample data, no accounts and no connection to your systems. On suitable projects I build it for free with an agreed scope, using AI agents for speed and reviewing the result myself.
It answers questions a document cannot. Whether the developer understood you. Whether the idea still makes sense when you see it on a phone or in a browser. Which parts you thought were essential turn out to be optional, and which small detail turns out to matter. And, for both of us, whether working together is comfortable. All of that is cheaper to learn with one screen than with a finished product.
- 01 Free basic demo One piece, sample data, no accounts. Agreed scope, no obligation.
- 02 First version or MVP Core journey, complete: accounts, stored data, errors handled. Paid, quoted in writing.
- 03 Full build Integrations, roles, payments, production and handover. Quoted in writing.
When can a developer give you a quote?
A serious quote needs a defined scope: which journeys, which accounts, which integrations, which platforms, and what stays out. Until that exists, any number is a guess dressed as a price, and the guess tends to be low. That is why I do not give a figure before the first conversation, and why the demo often comes first: it makes the scope concrete.
Once the scope is clear, you get the features, an estimated timeframe and the price in writing. Each project is quoted on its own, because there are no fixed packages that fit an app that talks to your systems. If the scope changes later, the change is agreed in writing as well, so the price moves for reasons you can see.
Questions before we start
Why can’t you give a price before the first call?
Because the price depends on integrations, accounts, payments and data, not on the number of screens. A short conversation is enough to find that out. Afterwards you get a written summary of the scope and, once it is defined, a written quote.
Does a demo commit me to anything?
No. The basic demo is free once we agree a scope that fits, and there is no obligation to continue. Using it in your business would need the paid implementation, because it runs on sample data without accounts.
Is a mobile app more expensive than a web app?
Often yes, when it has to be published in the app stores and work on two platforms. For many businesses a web app that installs on the phone is enough and costs less; we decide that in the first conversation.
What changes the price after the quote?
Changes of scope: a new integration, a new type of user, a feature that was not in the written scope. Each one is agreed in writing before it is built, so the price does not move without your decision.