You ask three agencies for a quote, compare the numbers, pick the one you trust most and sign a fixed scope. It feels safe: you know what you will pay and when you will get the product. Three weeks later, in the first check-in, something shows up that was not in the original document: a flow that made no sense once it was designed, a legal requirement nobody mentioned, an integration your first customer asks for. The agency's answer is polite but firm: that is a change request, and it gets quoted separately.
That is not bad faith. It is the logical result of a model that requires fixing the price before anything is built. The problem is not the agency, it is the premise: nobody can know exactly what a product needs until they build it and, above all, until real users touch it. A fixed budget gives you the sense of control every founder wants early on, but it is an illusion. Software is not construction with fixed blueprints; it is a learning process, and that learning almost always forces you to change something you signed.
This article is not trying to convince you that fixed-price is a scam. It explains why that model handles one unavoidable thing badly, change, and compares it with a different way of sharing that risk. You will not find price tables here: any number without knowing your project would be made up.
What Really Drives the Cost of Building Software
Ask what software development costs and the honest answer is “it depends”, on concrete things:
- Real complexity of the problem. A back-office screen is not the same as a flow with payments, role permissions and business rules that vary per customer. Complexity usually hides in what the mockup does not show.
- Team size and seniority. A senior team costs more per hour but makes fewer decisions you later have to undo. The cost of a bad architecture call never appears in the proposal.
- Required timeline. Compressing deadlines means parallelizing work or cutting quality. Neither is free.
- Integrations with existing systems. Third-party APIs, legacy data, internal tools: this is where most surprises appear and where estimates are weakest without prior exploration.
- Maintenance afterwards. Almost nobody budgets for it up front and almost every product needs it: updates, bugs, vendor changes, new features.
If someone gives you a fixed number without asking about these variables, it is most likely an optimistic estimate to close the deal, not a real budget.
Agency Fixed-Price vs Subscription Development: Two Ways of Sharing Risk
The core difference is not price, it is who carries the risk of a wrong estimate.
In the classic model, the agency fixes scope, timeline and price. If it estimates low, it loses margin or protects itself with rigid contracts and change clauses. If it estimates high, you pay that cushion up front. Either way, the incentive is to defend the signed document, not to improve the product.
In subscription or short-sprint models, you pay for sustained working capacity and get continuous deliveries. You are not buying a frozen scope; you are buying a team that works every week on the most valuable thing you know at that moment. The risk of mis-estimating is split differently: you set priorities, the team commits to quality and pace, and you can stop when the value no longer justifies the spend.
It is not magic, and it is not always better. If your project is tightly bounded, stable and its requirements are truly known (rarer than it seems), a fixed scope can work well. But if you are building a product, meaning learning, the fixed model pays poorly for that learning.
Scope Changes: The Hidden Cost the Classic Model Handles Badly
This is the real root problem. Scope changes are not an anomaly, they are the norm. Any team that has built product knows the first design never survives contact with real users intact. The question is not whether changes will happen, but how the working model is designed to absorb them.
With a fixed-price agency, a change triggers a near-bureaucratic process: document it, estimate it, negotiate it, sign an addendum and, often, pause development while the paperwork clears. All of that has a cost that never shows up on an invoice but you pay anyway: dead weeks, friction with the team, and the uncomfortable feeling of constantly negotiating with the people who are supposed to be on your side. The contract also rewards rigidity: what is in the document gets delivered; what is not gets billed separately. Meeting the spec is rewarded, not improving the product as you learn.
In a sprint or subscription model, change is handled differently because the model is built to iterate. There is no two-hundred-page document to protect: there is a short cycle, a demo, and a conversation about what to prioritize now that you know more than you did two weeks ago. If something changes, the next sprint's backlog is reordered. No addendum to sign, no negotiation to reopen, because the commitment is to the team's capacity, not to a frozen scope.
That does not mean anything goes under a subscription. You still have to prioritize with judgment, and someone has to say no. It means the cost of adapting to what the business actually learns is much lower, because the structure of the deal does not penalize it.
What to Ask Before Hiring a Software Agency (and the Red Flags to Watch For)
If you are about to hire a software agency, there are questions worth asking before you sign, not after the first conflict.
1. How do you handle a scope change mid-project? Ask for a concrete example. If the answer is vague or boils down to “we'll assess it when it happens”, you already know what is coming.
2. What happens if the project takes longer than planned? Not because it necessarily will, but because the answer tells you who carries the risk of a bad estimate. If it lands automatically on your wallet or your calendar, the fixed price is more of a sales tool than a realistic estimate.
3. Who will actually write the code? Ask for names, seniority and real availability, not the profile in the sales proposal. It is common for a very senior person to lead the sales call while a junior team does the daily work with little supervision. That need not be a problem if well managed, but you have a right to know.
4. Did you do technical discovery before giving me the number? Be wary of tight, cheap quotes delivered without anyone asking about your integrations, legal constraints or infrastructure. That number is a bet, not a serious software development budget, and when bets fail, you pay.
How We Approach It at Divolut
We do not think the goal is to give you the lowest budget on paper. We think every euro you invest in development should answer a clear business goal and be adjustable when context changes, because it always does. That is why we work with subscription development: weekly sprints, real demos and no forced lock-in. You pay for senior working capacity, not for a spec that breaks at the first check-in.
That means senior technical leadership from week one, not a salesperson who sells the project and a junior team that builds it unsupervised. If you need that strategic support on a more continuous basis, we also offer it as Fractional CTO: someone with senior technical judgment making architecture and prioritization decisions with you, not just delivering tasks.
We do not promise there will never be scope changes; we promise that when they appear, they will not turn into a tense negotiation but into a natural part of the next sprint.
If you want to talk through how to budget your project without locking into a scope that will not survive, let's talk.