Scope, budget and pricing model
How do uncertainty, priorities, capacity, and budget remain manageable without false certainty? A well thought-out estimate lays out what you are confident about, which risks are in play, and how choices affect budget, lead time, and complexity. During delivery, estimates, priorities, and progress continue to guide the conversation, while invoicing is based only on work actually performed.
Why we estimate this way
An estimate must support choices, not hide them
Do you work with one total price or a rough hours line where all functionality sinks away? Then you lose control. You no longer see what is truly needed, where the biggest uncertainty sits, or where you can still shift when planning or money gets tight.
That is why we link every requirement or functional block to a separate estimate and a risk judgement. That way you get a conversation on substance about importance and order, and it does not get stuck on one end amount.
From estimate to execution
Six ways to keep scope and budget manageable
We use Must, Should, and Could to show what is minimally required, what adds extra value, and what can safely move later.
We estimate per part, attach a risk class, and discuss which assumptions, dependencies, and starting conditions make the difference.
We do not hide project management, QA, design, or documentation inside feature hours. We show them separately when they are genuinely needed.
From time tracking to monthly invoicing, this is how we keep sight of actual work delivered.
After each sprint, we compare progress and estimate, and record decisions that affect budget or planning.
We explain when a feature-based project proposal fits, when a retainer is more logical, and when combining both makes sense.
Sharpen priorities
MoSCoW prioritisation
We use Must, Should, and Could to show what is minimally required, what adds extra value, and what can safely move later.
From estimate to execution
Early insight makes the project manageable
You use an estimate to make smarter choices.
We look beyond size alone. You always need to consider how parts relate to one another. A piece of work may look straightforward but still touch critical data, substantial integrations, or the operational heart of your processes. Other changes may deliver considerable value with little risk. Those relationships need to be visible early.
We turn this into a structured overview that helps you choose delivery order, phasing, and ambition. We also assess the existing foundation: whether documentation is adequate, colleagues can work in a reproducible development environment, and CI provides quick feedback. That overview keeps the full picture open for discussion.
Why fixed fee is not the default
Predictability without the wrong incentives
A fixed fee may look straightforward, but it often makes uncertainties less visible. The risk is that the conversation stops being about the best solution and turns into locking down Glossary · In briefscopeScope defines the boundaries of a project or assignment: which goals, activities and results are included and which are excluded.Read more, assumptions, and edge cases.
With Glossary · In brieftime and materialsTime and materials billing calculates the price after work has been carried out, based on the actual hours worked and costs incurred at agreed rates.Read more the dialogue stays focused on substance, priority, and what a solution is really worth. We do estimate upfront and discuss different scenarios, but we do not pretend that complex software fits neatly into a rigid total price.
When fixed fee can work
Not fundamentally against fixed prices
Sometimes a fixed fee fits fine, for example with a compact, cleanly bounded job with minimal dependencies. So we do not reject that idea upfront.
It is simply not the standard way most custom projects with business-critical software run best. Scope, integrations, Glossary · In brieftechnical debtTechnical debt is the extra work required because earlier software decisions make later changes harder, slower or riskier.Read more, and operational risks mean we work honestly with ranges and use time and materials on top of that, which we find clearer and healthier.
What this gives you
Visibility on what is essential and what can shift
Better grounding for budget and planning decisions
More insight into where time and budget go
A better ability to course-correct on substance along the way
Fewer surprises because risks are visible earlier
Frequently asked questions
Because software development always involves uncertainty, and you do not solve that by planning more precisely than you can substantiate. A range is more honest and more manageable.
Our starting point remains steering on estimates, scenarios, and hard priorities, with course correction at set moments. Time and materials does not pull the budget out of view; it makes it easier to follow during the project.
No. An estimate must still be substantiated and useful. We use it to make decisions about scope, planning, and risk, while keeping uncertainties visible.
Estimating provides footing to make informed decisions about what should be ready, when, and with which risks. Invoicing follows the work actually delivered.
Yes. When scope and priorities are explicit, you can adjust more deliberately without making the whole plan unclear.
Our hourly rate isn’t a secret, but it’s also not something we want listed in all kinds of records. Call Ewout at 0246690518 and he’ll be happy to tell you.
Is your question not listed here?
Get in touch