What a Custom App Really Costs: An Honest, Transparent Breakdown

Ask three agencies what a custom app costs and you'll get three numbers that don't even share a digit. One says four thousand, one says forty, one quietly says it depends and books a second meeting. None of them is lying, exactly — but none of them is telling you the thing you actually need to know, which is where the money goes and why your particular app lands where it lands. So let's open the hood.

I've written more app quotes than I can count, for businesses that range from a one-person trades operation to a regional chain. The single most common reaction to a price isn't shock at the total — it's confusion about the spread. How can the same three-word brief ("a booking app") produce estimates that differ by a factor of ten? The honest answer is that "a booking app" isn't a brief. It's a wish. The price lives in the hundred small decisions hiding underneath it.

This piece is the breakdown I wish every business owner had before their first call with a developer. No padding, no scare tactics, no upsell. Just the real cost components, the things that quietly double a budget, and a few honest ways to spend less without ending up with something you regret.

Why two quotes for "the same app" differ by 10x

Software isn't a product you pull off a shelf — it's labour, measured in the hours of skilled people. So the price of a custom app is, at its core, just scope × hourly rate × risk. Everything else is a footnote to those three things. When two quotes diverge wildly, one of those three numbers is being read very differently, and usually nobody has said so out loud.

Scope is the obvious one. "A booking app" might mean a single screen where customers pick a slot — or it might mean staff calendars, payments, reminders, a customer login, an admin dashboard, refunds, and a report the owner reads on Monday. Same three words, ten times the work. The cheap quote often assumes the small version; the expensive one quietly assumes the big one. Neither asked you which you meant.

Then there's risk, the part nobody likes to price. A vague brief, a client who hasn't decided what they want, an integration with a creaky legacy system — these don't just add hours, they add uncertainty. Experienced teams pad for uncertainty because they've been burned by it. A cheaper quote often hasn't priced the risk at all, which is exactly why it sometimes balloons halfway through.

Where the money actually goes

When people picture app development, they picture coding. Coding is real, but it's rarely even half the bill. A custom app is closer to building a small house than writing a document — there's design, plumbing, inspection and paperwork around the visible part. Here's how a typical budget splits up once you account for everything.

Two things tend to surprise people in that table. First, how much of the budget happens before a line of feature code is written — discovery and design aren't a luxury, they're the cheapest place to fix a mistake. Changing a screen in a sketch costs minutes; changing it after it's built costs days. Second, how real the testing line is. Skipping it doesn't save money, it just moves the cost to your launch week, with interest.

Discovery and design: the part everyone wants to skip

Discovery is where you turn "a booking app" into a precise list of screens and rules. It feels like overhead because nothing is being built yet. But every hour here saves several down the line, because it's where ambiguity gets killed while it's still cheap. A team that quotes you a price with no discovery phase is either guessing, or planning to bill you for the discovery later under a different name.

Core development: the visible engine

This is the code that makes your idea run — the screens people tap, the logic behind them, and the database quietly remembering everything. It's the biggest single slice, and it scales almost directly with scope. Every feature you add is more to build, more to test, and more to maintain forever after. This is the line where "wouldn't it be nice if" gets expensive fast.

Integrations: the deceptively pricey bit

Connecting your app to other systems — taking a card payment, sending an SMS reminder, syncing a calendar, pulling data from the accounting software you already use — looks small on a feature list and lands surprisingly heavy on the invoice. Each connection is a small project of its own, with its own quirks and failure modes. One well-behaved payment integration is fine. Five tangled integrations with an ageing in-house system is where budgets go to die.

The costs nobody puts in the quote

Here's where a lot of owners get a nasty surprise twelve months in. The build is a one-off number; an app is not a one-off thing. Software is alive — phones update, rules change, your business grows — and a living thing needs feeding. The quote you sign is the price of birth, not the price of ownership.

None of this is a scam or a hidden trap — it's just the part that doesn't fit neatly on a one-page quote, so weaker partners leave it off to look cheaper. A good one tells you about it up front, even though it makes their first number look bigger. Ask explicitly: what does this cost me to run for a year after launch? The quality of the answer tells you a lot about who you're dealing with.

What quietly doubles the price

Some things add cost in proportion to the value they bring — fair enough. Others add cost out of all proportion, usually because of how the work is structured rather than what the app does. These are the levers worth understanding, because a few of them are entirely within your control.

• Two platforms instead of one. A native iPhone app and a native Android app are, roughly, two builds. Cross-platform tools or a web app can collapse that back toward one. This single choice can move the total more than any feature.
• Custom design over sensible defaults. A pixel-perfect, fully bespoke interface costs real money to design and build. A clean, conventional one that uses proven patterns is faster, cheaper, and often easier for customers to use.
• Changing your mind after the build starts. Decisions are cheap on a whiteboard and expensive in code. The most common budget overrun isn't bad estimating — it's scope that kept growing because nothing was nailed down.
• Real-time, offline, or heavy data. "It should work without signal" or "updates must appear instantly for everyone" are reasonable requests that quietly multiply the engineering underneath.
• Integrating with something old and undocumented. Connecting to a modern, well-built system is routine. Connecting to a fifteen-year-old in-house tool with no documentation is archaeology, and it's billed by the hour.

A real example: the €60k quote that became a €14k app

A few details changed for privacy, but the shape of this is true and entirely typical. A regional service company — think a dozen field staff and a busy office — came to us frustrated. They wanted a custom app for their customers to book jobs, track progress, and pay. They'd already had a quote elsewhere for around €60,000, plus a meaty monthly fee, and it had scared them off the whole idea for the better part of a year.

When we actually mapped what they needed — not what they'd been quoted — the picture looked very different. The first quote had assumed two fully native apps, a bespoke design from scratch, a real-time dispatch system, and a custom admin platform to replace tools they already owned and were quietly happy with. It was, technically, a perfectly good app. It was also an answer to a question they hadn't asked.

What we actually did

We spent the first sessions doing nothing but discovery — pulling the wish apart into "the business breaks without this" versus "that would be nice someday." The must-haves were narrower than anyone expected: a clean way for customers to request and track a job, automatic reminders, and online payment. The real-time dispatch and the custom back office turned out to be solutions to problems their existing software already handled fine.

1. 1
   Cut the scope to the real job

   We dropped the features that solved problems they didn't have, and kept a tight list the business genuinely couldn't run without.
2. 2
   Chose one cross-platform build

   Instead of two separate native apps, a single cross-platform app covered both iPhone and Android — roughly halving the core development.
3. 3
   Used proven design patterns

   A clean, conventional interface instead of a bespoke one. Customers found it easier to use, and it shaved weeks off the timeline.
4. 4
   Connected, didn't replace

   We linked the app to the office software they already paid for, rather than rebuilding it. The expensive 'custom admin platform' simply vanished from the scope.

The result was a build of around €14,000, live in a few months, with running costs they could predict. It is not as sprawling as the €60k version — and it does not need to be. It does the job the business actually had. A year on, they've added two small features on top, paid for out of the money the first version saved them. That's the whole pattern: start with the real job, earn the extras with results.

How to keep the cost sane without cutting corners

Spending less on a custom app isn't about haggling the hourly rate down or finding the cheapest team you can. That's how you end up paying twice. It's about being deliberate with scope, sequencing, and decisions — the three things that genuinely move the number. Here's where the real savings live.

First, build the smallest version that's actually useful, then grow it. A focused first release that does one job well gets you live faster, costs a fraction of the all-in-one dream, and — crucially — teaches you what to build next from real customers instead of guesses. Second, make your decisions before the build starts; indecision is the most expensive thing you can bring to a project. Third, connect to what you already own rather than replacing working tools, and only rebuild something when it's genuinely holding you back.

Common questions