The honest answer to the cost question is a counter-question: what should the app do? Everything else — price calculators, “apps from …” ads — just moves the surprise to later. An app’s price is set by its scope, and scope can’t be known before a conversation about screens, integrations and user roles. What you can understand up front: which factors drive the effort, where saving is sensible, and where cutting corners costs double later.
The five drivers the effort hangs on
Screens and user roles. Every view needs to be designed, built and tested — and an app with admin, employee and customer roles isn’t one app, it’s three. The screen count is the quickest proxy for project size.
The backend. An app that only displays things is cheap. An app that syncs data, manages users, sends push notifications and talks to your inventory system consists mostly of server logic nobody sees. Exactly that part is what lay estimates forget most often.
Interfaces to existing systems. “The data comes from our ERP” is a sentence that can hide anything — a clean REST API or a twenty-year-old system that only knows CSV exports. Integrations are the line item with the widest spread.
Offline capability and sync. If the app must work without a connection and reconcile later, complexity jumps: conflicts, versions, partial sync. Often indispensable for field service; many other cases get by without it.
Platforms. Cross-platform with Flutter or React Native saves the second codebase — but not half the budget, because concept, design, backend and testing stay the same size. Two separate native apps are the most expensive route and need a good reason.
Where saving is smart — and where it turns expensive
Smart saving means saving scope: a genuine MVP with the two or three core features delivers lessons before the big budget flows. Standard components for login, payments or maps beat custom builds almost every time. And an honest concept phase that removes features is the cheapest development work there is.
Cutting corners gets expensive in three places. First, the concept: what stays unclear in conversation gets rebuilt three times in code. Second, testing: bugs your customers find cost reputation and hotfix weekends. Third, the years after launch — yearly OS releases, framework upgrades and security updates arrive whether planned or not. An app without ongoing maintenance is a renovation case after two years, and the renovation costs more than the maintenance months you saved.
How to spot a serious quote
A usable quote states its assumptions: which features are in, which explicitly aren’t, what the backend covers, who delivers design and content, how changes are handled, and what happens after launch. A bare total without assumptions isn’t an estimate, it’s bait — the difference gets billed later as “change requests”. So never compare quotes by the bottom line; compare what the bottom line buys. How we set up projects ourselves is described here — including the stages from concept to handover.
Have an app idea and want an honest effort estimate instead of a catalogue number? Get in touch — the first conversation costs nothing, and afterwards you’ll know where you stand.