“How much does it cost to build this software?” is the question we answer most often at Soamee. And the honest answer always starts the same way: it depends. But “it depends” cannot be the end of the conversation, so in this article we open up our kitchen: the step-by-step method we use to estimate a software development budget, the variables that really move the price and how to spot trap quotes.
If you are looking for concrete figures by project type, we have a complementary guide with market ranges: how much app development costs in 2026. Here we focus on the method: how that number is built.
The Variables That Really Move the Price
A software budget is not calculated by screens or “pages”. These are the highest-impact variables, ordered by real weight in our experience:
| Variable | Price impact | Why |
|---|---|---|
| External integrations (ERP, CRM, payments, third-party APIs) | Very high | Every external system brings surprises: poor documentation, rate limits, sandboxes that do not replicate production |
| Complex business logic | Very high | Rules, exceptions and edge cases multiply the invisible work |
| Security and compliance (GDPR, healthcare, fintech) | High | Audits, encryption, traceability, anonymization: work that does not show in the demo |
| Number of roles and permissions | High | Every role multiplies the flows to design and test |
| Custom design vs existing design system | Medium-high | Designing from scratch adds weeks of iterative work |
| Multilingual and localization | Medium | It is not just translating: formats, currencies, routes, per-language SEO |
| Number of screens | Medium | It matters, but far less than people believe |
| Native apps vs web | Medium | Two native platforms ≈ 1.6-1.8x the cost of one |
The practical conclusion: two projects with the same screens can differ 3x in price because of what happens under the surface.
Our Estimation Method, Step by Step
Step 1: Understand the Problem, Not the Solution
The first meeting is not about features, it is about business: what problem the software solves, who will use it, what happens if it is not built. Many projects get cheaper right here, because the solution the client had in mind was bigger than their actual problem.
Step 2: Define the Scope in Stories, Not Screens
We break the product down into user stories (“as a manager, I want to approve invoices from my phone”) grouped into epics. This inventory is the backbone of the budget: everything listed gets estimated; everything not listed is explicitly out of scope.
Step 3: Estimate in Ranges with the Team That Will Execute
Each epic is estimated by the technical team that will build it (not a salesperson), in optimistic-pessimistic ranges. We use data from similar past projects as calibration: historical memory is worth more than any formula.
Step 4: Add the Invisible Work
This is where cheap quotes cheat. A professional project includes line items that are not “features”:
- Management and communication: 10-15% of the total
- QA and testing: 15-25% depending on criticality
- DevOps and deployment: CI/CD, environments, monitoring
- Uncertainty buffer: 10-20% depending on how closed the scope is
If a quote does not break down these items, they are either hidden in the price or simply absent (and you will pay for them later, in bugs and delays).
Step 5: Present a Range with Explicit Assumptions
The result is never “€42,500”. It is something like: “Between €35,000 and €48,000, assuming the payment gateway is Stripe, the design starts from your current system and the ERP integration exposes a documented REST API”. Every broken assumption moves the number, and everyone knows in advance which ones they are.
Why a Wide Range Is a Sign of Honesty
It seems counterintuitive: shouldn’t an expert agency give you an exact figure? Not at the beginning — and whoever does is telling you a story.
Uncertainty at the start of a software project is a measurable fact, not an excuse. The classic “cone of uncertainty” in software engineering shows that initial estimates can easily deviate between 0.5x and 2x until the scope is closed. Faced with that, there are three possible responses:
- Exact and low figure → sales hook; the margin is recovered with “extras” mid-project
- Exact and inflated figure → they added a huge cushion without telling you; you pay for the uncertainty even if it never materializes
- Honest range with assumptions → they tell you the truth and give you the mechanism to narrow the range (close the scope, run a discovery phase)
The range narrows with work: after a discovery phase or a first sprint, the estimate for the rest becomes far more precise. Distrust premature precision, not the range.
How to Compare Quotes from Several Agencies
Receiving three quotes and sorting by price is the worst way to decide. Compare against this checklist:
- Equivalent scope: did they estimate the same thing? Ask for the breakdown by epics/modules and check what each one includes
- Invisible line items: do QA, management, deployment and documentation appear? Or is the price just “coding”?
- Written assumptions: what did they take for granted? That is where future arguments live
- Concrete team: who will work on your project (seniority, dedication)? A low price with unsupervised junior profiles ends up expensive
- What happens with changes: how are scope modifications managed and priced?
- Ownership and exit: is the code yours from day one? Repository under your account?
- Working model: fixed price, time & materials or dedicated team — each distributes risk differently
On that last point: fixed price shifts the risk to the agency (which charges for it as a cushion), and time & materials shifts it to the client (who needs trust and visibility). For projects with uncertainty, a reasonable hybrid is fixed-price discovery + sprint-based development.
If you are also weighing the alternative of hiring internally, we have a full comparison of agency vs in-house team.
Red Flags in a Software Quote
- Price far below the rest without a structural explanation (location, smaller scope): it usually ends in extras or poor quality
- Exact figure without closed requirements: premature precision = marketing
- No breakdown: a single total number prevents comparing and negotiating
- No assumptions or exclusions: everything unwritten will end up in a dispute
- QA and management “included for free”: they do not exist for free; either they are not done or they are hidden
- Pressure to sign now with expiring discounts: decisions worth tens of thousands of euros are not made under artificial urgency
- Everything is “yes”: an agency that never questions your scope is not estimating, it is selling
And the Green Flags
- They ask you many questions before giving a number
- They propose cutting scope to fit the budget (selling you less is the best sign of honesty)
- A range with explicit assumptions and a plan to narrow it
- A transparent breakdown including QA, management and deployment
- Verifiable references from projects of similar size
Frequently Asked Questions
Why do agencies give ranges instead of a fixed figure?
Because at the start there is real uncertainty: unfinished requirements, integrations yet to be discovered. An honest range reflects that uncertainty; an exact figure before defining the scope is marketing, not estimation.
How do I compare quotes from several agencies?
Compare scope, not just price: breakdown by line items, assumptions, concrete team and change management. Two quotes with the same figure can cover radically different scopes.
What makes a project more expensive?
External integrations, security and compliance, complex business logic and mid-project scope changes. The number of screens matters less than people think.
Is a much cheaper quote a bad sign?
Almost always: misunderstood scope, quality cuts or future extras. Ask for the breakdown and the assumptions before deciding on price.
Conclusion
A good software budget is not a figure: it is a decomposed scope, estimated by the people who will execute it, with the invisible work included and the assumptions in writing. A wide range at the beginning is not weakness, it is honesty; precision arrives when the scope closes, not before.
If you have a project on your hands and want to see this method applied to your case, book a free consultation: you will leave with a realistic range and with the right questions to evaluate any quote you receive — ours or anyone else’s.