You describe the same app to three developers and get back three numbers: €12k, €32k, and €50k. They are all pricing different things, because your brief left most of the expensive parts unspecified, and each of them filled the blanks differently.
That’s the first thing to understand about software. There is no fixed price, because you are not buying a product off a shelf. You’re buying a stranger’s estimate of how many hours of skilled work, and how much risk, sit between your idea and something that runs live for real users without falling over. The number reflects that estimate. When the number surprises you, it’s usually because the estimate priced something you didn’t know you were asking for.
This post is a breakdown of what’s actually inside that number, so the next quote you receive reads like a well defined document.
What you’re actually paying for
Strip a software project down and the cost is roughly: hours of skilled work, multiplied by an hourly rate, plus a margin for the risk that the hours were underestimated.
The mistake businesses make is reading the quote as if it’s mostly the rate. It rarely is. Two developers at the same rate can quote 4x apart on the same spec, because they disagree about the hours it takes to complete it.
The cost drivers, in the order they surprise people
1. Scope clarity: the ambiguity tax
The single biggest driver of a quote is how clearly the thing is defined. “A booking system” is not a feature, but a whole category of them. Does it take payments? Refunds? Partial refunds? Does it handle timezones, cancellations, waitlists, recurring bookings, staff calendars, no shows? Each of those is real work, and if your spec doesn’t say, the developer either asks (good) or assumes (expensive, in one direction or the other).
A vague brief with open questions gets priced one of two ways:
- A careful developer prices the pessimistic reading and quotes high, covering themselves for the version of the project that takes the most time.
- The one who just wants the deal prices the optimistic reading, wins the job, then bills you for “changes” every time reality turns out bigger than what they anticipated.
The clearer your spec, the tighter and cheaper the quote, because you’re paying for software instead of paying for someone’s uncertainty about what you meant.
2. Integrations: every wire to the outside world
Software rarely lives alone. It talks to a payment provider, an email service, an accounting system, a CRM, a government portal, an obscure legacy database. Every one of those connections is a small project of its own: reading someone else’s documentation, handling their outages, matching their data model to yours, and dealing with the cases where their system behaves differently in production than it did while testing it.
Non technical people consistently underprice this because from the outside an integration sounds like flipping a switch (“just connect it to Stripe”). From the inside it’s where a surprising share of the hours go. A good rule: count the external systems your app has to touch, and assume each one is a separate line on the invoice.
3. Your existing data
If this app replaces something (a spreadsheet, an old system, a pile of paper), your existing data has to move into it. That data is almost never clean. It has duplicates, missing fields, three different spellings of the same customer, dates in four formats, and rules that only ever lived in one person’s head. Migrating it is part engineering, part detective work, and it’s easy to underestimate until someone actually starts looking into it.
A brand new app with no old data to import is meaningfully cheaper than the same app that has to swallow ten years of messy records. If you have existing data you want to keep, say so early. It changes the number.
4. Compliance and where the data lives
If you’re handling personal data in the EU, GDPR isn’t optional and it isn’t free. Data residency, consent, the right to be forgotten, breach handling, audit trails, where your servers physically are. In regulated industries (health, finance, anything touching payments directly) the bar is higher again, and “we’ll sort it later” is a very expensive sentence.
5. How many people, how reliably
“It works on my laptop” and “it works for 5,000 people at once, at 3am, without me watching” are different products with different price tags. The non functional requirements (how many users, how fast, how reliable, what happens when a server dies) quietly set a floor under the cost. An internal tool can cut corners a public app for 50k users cannot.
Be honest about scale, in both directions. Overstating it (“build it to handle millions”) buys expensive engineering you won’t use for years. Understating it can force a costly rewrite if your business outgrows what you built for.
6. How custom the interface has to look
A functional interface built from ready made building blocks is cheap and perfectly fine for most internal and B2B software. A pixel crafted, branded, animated experience where the design is the product is a different budget. Neither is wrong. But “make it look really polished” is a cost driver people forget to mention and then are surprised to see priced.
7. Who’s holding the keyboard
A freelancer, a local agency, and an offshore team of five will quote very differently, and the number is only half the story. The other half is the risk, the communication overhead, the timezone gap, and what happens when it goes wrong. Cheaper per hour often means more hours, more management on your side, and a higher chance of a rewrite. Sometimes it’s genuinely the right call. But optimising for the lowest rate rarely wins on total cost.
8. How innovative the idea is
The more original what you’re building, the more of the early work is simply figuring out what the work is. A familiar shape, another CRM, another booking flow, has a known cost. Something genuinely innovative doesn’t, because nobody has built exactly this before, and no honest person can hand you a firm number for something they haven’t seen yet. That’s why larger or more novel projects start with a discovery phase rather than a headline price for the whole system.
I usually run that first discovery for free. But if it turns out the project is far bigger than it first looked, I’ll tell you that plainly, and the deeper work after that point gets priced too. Pretending a large project is a small one would only set us both up to fail.
Be more suspicious of a confident fixed price on a vague spec than of a developer who wants to scope it first.
So what are the actual numbers
You want numbers, so here are some. In the EU, for custom software built by a competent freelancer or small studio, the rough brackets look like this:
- A tight, well scoped internal tool (one clear workflow, few integrations, modest scale): roughly €5k to €20k.
- A real product MVP (several workflows, a few integrations, user logins, payments, a decent UI): roughly €20k to €50k, climbing fast with each integration and compliance requirement.
- A larger platform (many workflows, heavy integrations, regulatory weight, real scale): €80k+. This is where discovery first pricing stops being optional.
Depending on the eight drivers above, the real price can land well outside these brackets. That’s the honest answer.
How to read your quote
Next time you receive an estimate, read it as a set of decisions someone made on your behalf:
- What did they assume was in scope? If it’s not written down, it’s not agreed, and it’s where the “unexpected” costs come from.
- How did they count the integrations? Each external system should be visible in the breakdown.
- Did they price the data migration, or ignore it? If you have existing data and it’s not mentioned, they either missed it or they’re planning to bill it later.
- Is compliance in there? If you’re in the EU handling personal data and GDPR isn’t referenced anywhere, be careful.
- Fixed price or time and materials, and does that match how clear the spec is? A fixed price on a fuzzy brief is a fight waiting to happen. The reverse is also worth watching: when the spec is razor sharp the work is predictable, so a fixed price would spare you the overrun risk. Hourly billing on that same spec can be perfectly fair, but it quietly shifts a risk the developer was well placed to carry.
One thing to keep straight while you’re pricing all this: the quote you’re reading is for building the app. The servers it runs on are a separate monthly bill that arrives for as long as the app is alive. I cover this in who pays for the server, and why.
The takeaway
The reason the same idea gets priced 4x apart is almost never that one developer is greedy and another is generous. It’s that a software quote is mostly a measurement of everything you haven’t decided yet, and different people measure those parts differently. The most powerful thing you can do to control the cost isn’t to negotiate the rate. It’s to remove the ambiguity, because every question you answer up front is a question the developer no longer has to price as risk.
If you’re staring at a quote you can’t quite read, or numbers that don’t make sense together, I would be happy to help you see through it before you sign anything.