How long does custom software actually take?

Ask a development shop how long your project will take and you will usually get a range wide enough to be useless, delivered with enough confidence to sound like an answer. Here are the real numbers, and more usefully, what actually moves them.

The rough shape

• Something you can click: days. Not a mockup, a working prototype with your terminology in it. If nobody can show you this inside the first week or two, that tells you something about how they work.
• A focused tool or single workflow: one to two months. One job done properly. A quoting tool, an intake form that feeds your system, a scheduling board.
• A platform running a real slice of the operation: three to six months. Multiple user roles, integrations with what you already run, real permissions.
• A system the whole business depends on: six months and up. A custom ERP is not a bigger version of a small app. It is more months of more people.

Those ranges assume you see working pieces the whole way through. A project that disappears for six months and reappears finished is a different and much riskier proposition, whatever the timeline says.

What actually drives the number

Not screen count. Nobody has ever been slowed down by drawing another form. Four things drive real timelines:

Decisions

Every branch in your process is a decision somebody has to make, and roughly a third of them are decisions nobody has ever had to make explicitly before. What happens when a customer orders below the minimum? Who can override a price, and does it need approving? These were handled by judgment, and judgment does not port into software without someone choosing a rule.

This is the single largest driver, and it is largely on your side of the table.

Integrations

Connecting to a system with a good modern API adds days. Connecting to one with file drops, a 2011 SOAP endpoint, or an undocumented database adds weeks, and the discovery of which one you have often happens after the estimate.

Data migration

Whatever you budget here, the overrun lands in calendar time rather than money. The work is rarely difficult. It is slow, because every anomaly in the old data needs somebody to decide what it should become, and that somebody works for you and has a day job.

We have written separately about why old data is the part that overruns. For planning purposes, assume it runs alongside the build from roughly the midpoint, and assume it is what moves your go-live date rather than the software.

Approvals

A build waiting on a review is not a build. If feedback takes a week to come back, and there are twelve review cycles, that is three months of calendar sitting in your inbox.

The delays that are yours

Worth saying plainly, because a good shop will not want to say it to your face during the project:

• The person who knows how it works is too busy. Every build needs a few hours a week from whoever actually understands the process. If that person is also your best operator, they will be pulled away, and the project slows to the rate of their availability.
• Feedback arrives late and changes direction. Changing your mind in week two is free. Changing it in month five, after four things have been built on top of the earlier decision, is not.
• Sign-off has more people in it than anyone mentioned. Find out early who genuinely has to approve, and get them into a review rather than a summary email.

The delays that are ours

Underestimating an integration. Discovering the data is worse than the sample suggested. Building something that turned out to solve the wrong problem, which happens and is the reason for showing you working versions early rather than at the end.

Where we land on this is that timeline risk sits better with us than with you. Our plans bill monthly rather than as a fixed project, and billing starts when version 1.0 is live. If the work turns out to be bigger than anyone thought, that costs us weeks. It does not turn into a change order and an argument.

The question worth asking instead

"How long until it is done" is a less useful question than "how long until it is doing something useful". Those have very different answers. A platform that takes eight months to finish can still have your dispatch team off the whiteboard in month two, and that is the number that changes your year.