What an app really costs: the three-year number nobody quotes

There is no honest single number, and anyone who names one before reading your requirements is guessing. The useful framing is this: development is typically 40-60% of the three-year cost, so a build quote is not the decision figure. The drivers are scope, how many platforms you ship, and how long you keep the thing alive. Treat every range you read, including ours, as illustrative until someone has looked at your case.

No. One codebase for iOS and Android saves real money, but you still test on both, still hit platform-specific bugs, and still need someone who knows each store's review rules. Budget around 60-70% of two native apps rather than 50% — illustrative, not a quote. The saving is genuine; it is simply smaller than the pitch, and the gap is exactly the part nobody puts in the slide deck.

Often the website is enough, and saying so costs us work. If the goal is 'our customers should reorder easily', a fast mobile web experience does that today — no store, no install, no review queue. Build an app when you genuinely need the camera, offline work, push, or a home-screen habit. The test: will people open this more than once a week? If not, you are buying a store presence, not a product.

More than most budgets admit. OS version updates break things you never touched, store review rules move, and crash reporting and analytics have to be paid for and actually watched. Since the build is typically under half the three-year cost, the years after launch are the larger half. Put maintenance in the plan as a standing line item, not as a contingency you quietly hope never to spend.