How long does it take to build custom business software?
Most timeline questions get answered with a number that turns out to be wrong. Here is what actually drives the schedule, and how to structure a project so you see value early.
The honest answer is that it depends, which is useless on its own. So here is the structure behind the estimate: what a realistic first version takes, what makes the number grow, and why the delivery date matters less than most people assume.
Typical timelines by scope
These assume one developer working steadily and a client who responds to questions within a day or two. Both of those assumptions matter more than they sound.
| Scope | Typical timeline | What you get |
|---|---|---|
| One workflow | 4 to 8 weeks | A single painful process replaced end to end |
| Departmental system | 3 to 5 months | Several connected workflows, reporting, a few integrations |
| Multi-site system | 6 to 12 months, staged | Multiple locations, roles and permissions, legacy migration |
Notice that the largest option says staged. Any project running past about four months should be delivering usable pieces along the way rather than everything at the end. More on why below.
What actually drives the number
Four things account for most of the variation between a six week project and a six month one.
Number of distinct workflows
Not screens, processes. Tracking leads through a pipeline is one workflow. Tracking leads, booking installs, raising invoices and routing engineers is four, and it takes roughly four times as long.
Integrations with other systems
The cost here depends almost entirely on the quality of the other side. A modern, well documented API might take two days. A legacy system whose only export is a nightly CSV can take two weeks, and will keep costing you in maintenance afterwards.
The state of your data
This is the single most underestimated item in the industry. Ten years of records spread across inconsistent spreadsheets need deduplicating, reconciling and validating before they are worth moving. It regularly takes longer than building the feature that uses the data. There is more detail in our guide to moving data off spreadsheets.
How fast decisions get made
This one is entirely on your side of the table, and it is the most common cause of slipped dates. A question that waits five days for an answer adds five days to the project, and questions come up constantly in the early weeks.
The part nobody budgets for: your time
Quotes describe developer effort. They rarely describe yours. A realistic project needs a few hours of your time each week for the first month or two, covering process walkthroughs, decisions, and reviewing what has been built.
That is not overhead, it is the mechanism that keeps the system matching how you actually work. Projects where the client goes quiet for a month tend to produce software that technically works and practically does not fit.
Why staged delivery beats a launch date
The instinct is to specify everything, agree a date, and wait. It feels safer because there is a single number to hold someone to. In practice it is the riskier approach, for three reasons.
- You find out whether the software fits your business only at the very end, when changing it is most expensive.
- Your business will change during a six month build, and a fixed specification written in month one will not reflect that.
- You get no value at all until the whole thing lands, so the investment sits idle for months.
Staged delivery inverts all three. The first usable piece lands in weeks, you use it in anger, and what you learn shapes the next piece. It also means that if the project stops for any reason, you still keep something that works.
A launch date tells you when the work ends. Staged delivery tells you when the value starts.
Five things that make projects slip
- Scope added mid build. Every addition costs its own build time plus the time to re-test everything it touches. Park good ideas for phase two rather than absorbing them.
- Data that turns out to be messier than expected. This is why a proper look at your data should happen before the estimate, not after.
- A third party system that does not behave as documented. Common with older software, and rarely predictable in advance.
- Slow feedback. Covered above, and worth repeating because it is the most fixable.
- Unclear ownership on your side. If three people must agree on every decision, expect the schedule to reflect that.
What a realistic first phase looks like
If you are starting from nothing, the version that works best is narrow and quick. Pick the single workflow costing you the most time, build only that, and put it in front of real users within about six weeks.
You get three things from this. A measurable saving you can point at when funding the next phase, a genuine test of whether you and the developer work well together, and a much better sense of what phase two should contain. Compare that against committing to a twelve month programme on the strength of a specification document.
If you are weighing that against buying something off the shelf instead, this comparison covers where each option makes sense.
Frequently asked questions
Only up to a point. Adding developers to a small project often slows it down, because coordination overhead grows faster than output. What genuinely speeds things up is narrowing scope, having clean data ready, and making decisions quickly.
With staged delivery, usually four to eight weeks for the first working piece. That first release will not do everything, but it should replace one real process end to end so the benefit starts immediately rather than at the end of the project.
Ask this before you sign. A reasonable arrangement splits the work into phases with their own scope and price, so overruns are contained and visible rather than accumulating silently. Agree in advance how changes to scope are priced.