Contents
Software projects overrun mainly because of poorly defined scope, slow decisions on the client side and underestimated integrations or data, rarely because of the code itself. A 1 to 2 week scoping phase, a fixed price, approved mockups and delivery in tested batches greatly reduce the risk.
Budget and schedule overruns are not an inevitable part of software development. They have well-known causes, and those causes almost always show up before the first line of code. Here are the ones I watch for, the signs that should worry you, and how I structure a project to neutralize them.
The real causes of overruns
The code is rarely the culprit. Overruns come from how the project is organized.
- Fuzzy scope. “A tool to manage orders” could mean three weeks or six months of work. Until the screens, rules and edge cases are written down, nobody can hold a budget.
- Slow decisions. A question left unanswered for ten days blocks part of the development. Multiply that by the number of open questions and the whole schedule shifts.
- Underestimated integrations. Connecting an ERP, accounting software or a marketplace depends on the quality of their documentation and API, which you sometimes discover late.
- Starting data. Migrating years of history full of duplicates, inconsistent formats and repurposed fields often takes longer than planned.
- Requests as you go. Each addition seems small. Added up and unmanaged, they blow up the scope.
- The tunnel effect. A provider who delivers everything at the end finds out too late that they misunderstood a need.
Warning signs and remedies
| Cause | Warning sign | Remedy |
|---|---|---|
| Fuzzy scope | Quote with no list of screens or rules | Written scoping, approved requirements document |
| Slow decisions | Questions unanswered for more than a week | Named point person, regular check-ins |
| Integrations | “We’ll deal with the connection at the end” | Test the third-party API during scoping |
| Data | No data sample provided before the quote | Analysis of a real export, migration priced separately |
| Requests as you go | A growing list of “small things” | Every addition estimated, then approved or deferred |
| Tunnel effect | No demo for over a month | Delivery in batches, tested by your team |
The method that limits the risk
My process is built to address these causes one by one.
- A 1 to 2 week scoping phase before any commitment to development: workshops, requirements document, fixed quote and schedule. It is the most cost-effective step of the project.
- Fixed prices. The budget is set against a written scope. If you want to compare with time-based billing, the page on fixed price or time and materials explains the pros and cons of each.
- Clickable mockups (1 to 3 weeks) approved before development: fixing a screen takes an hour in a mockup and a day once it is coded.
- Development in batches, each tested by your team before the next. A misunderstanding shows up after a few weeks, not at final delivery.
- New requests are always discussed and decided, never slipped in silently.
The timelines I give remain indicative, because they also depend on your team’s availability to review and test. The scoping schedule spells out what is expected from each side.
Building in a margin without inflating the budget
A well-scoped project does not need an oversized envelope, but it does need a reasonable reserve for the choices you will make along the way. An illustrative example, with made-up amounts to replace with your own: for a business application quoted at $15,700 (€14,000)excl. VAT on a fixed-price basis, a 10 to 15% reserve lets you accept one or two changes discovered during testing without reopening the budget discussion.
To place your project within my pricing, the estimator gives you a range in one minute. Focused projects fall between $6,800 and $22,400 (€6,000–€20,000)excl. VAT, over 1 to 3 months.
When custom software is too risky for you
There are situations where I advise against starting development:
- nobody on your side can be available to review and test;
- the process changes every month and has not settled;
- the deadline is fixed and too short for the minimum scope;
- an off-the-shelf product already covers the essentials: configuring it costs less and carries fewer unknowns.
In those cases, it is better to wait, reduce the scope or choose an existing tool.
Where to start
- Describe your need on one page: who uses the tool, for which tasks, and which software it must connect to.
- Gather a sample of your data and the documentation for the tools to connect.
- Book 30 minutes with me: I will tell you which risk areas I see and how to scope them.
If a project has already gone off course, an audit takes stock of what exists before you decide what comes next. For a new project, the full process is on the business apps page.
Frequently asked questions
Does a fixed price really protect against overruns?
It protects the budget for the scope described in the quote. Anything outside it becomes a priced change order, which you can accept or decline. That is why scoping quality matters so much: a fixed price on a vague scope protects no one.
What if a new request comes up mid-project?
Write it down, estimate it, then decide: add it to the current batch with a price and schedule adjustment, swap it for a less useful feature, or push it to the next batch. Change is not what causes overruns; unmanaged change is.
How much time should our team set aside?
Plan for one point person available a few hours a week to answer questions, approve mockups and test each batch. Without them, decisions pile up and the schedule slips, whoever the provider is.
Our project already went off the rails with another provider. What now?
Start with an assessment: what works, what is missing, how good the code is. An express audit ($660 (€589)excl. VAT) or a full audit ($2,300 (€1,990)excl. VAT) lets you decide between taking it over, targeted fixes or a partial rebuild.