How long does custom software take to build?

Ask a development firm how long your project will take and you'll often get a range so wide it doesn't help you plan, delivered confidently enough to sound like an answer. Here are the timelines we see in practice, and what makes them longer or shorter.

Roughly how long things take

You should have something you can click on within days. We mean an early working version with your own terms in it that you can try, rather than drawings of screens. If nobody can show you that in the first week or two, it tells you something about how they work.

A focused tool that does one job properly takes one to two months. Think of a quoting tool, an intake form that feeds straight into your system, or a scheduling board.

A system that runs a real slice of your operation takes three to six months. That's where you have several kinds of users, connections to the software you already run, and proper controls over who can see and change what.

A system the whole business depends on takes six months and up. A custom ERP is a different kind of project from a small app, with more people working on it for more months.

All of those assume you see working pieces the whole way through. A project that disappears for six months and comes back finished is a much riskier proposition, whatever the timeline says.

What decides the timeline

Four things drive real timelines, and the number of screens isn't one of them.

The first, and the largest, is 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 that need approval? Until now, people handled those with judgment, and software can't use judgment until someone turns it into a rule. Most of this sits on your side of the table.

The second is connecting to your other systems. If the system on the other end has a good, modern way to connect, that adds days. If it only exchanges files, uses a connection method dating from 2011, or keeps its data in a database nobody documented, it adds weeks. Often nobody finds out which kind you have until after the estimate.

The third is moving your old records over. Whatever you budget for it, the overrun shows up as extra calendar time more than extra cost. The work is rarely hard, but it's slow, because every oddity in the old data needs someone to decide what it should become, and that someone works for you and already has a day job. We've written separately about why the old data is the part that overruns. For planning, assume it runs alongside the build from about the halfway point, and that it, more than the software, is what will set your go-live date.

The fourth is approvals. While the build is waiting on a review, nothing moves. If feedback takes a week to come back and there are twelve review rounds, that's three months of the schedule spent sitting in your inbox.

The delays that come from your side

A good firm won't want to say this to your face mid-project, so we'll say it here. Every build needs a few hours a week from whoever understands the process best. If that person is also your best operator, they'll keep getting pulled away, and the project moves at the pace of their free time.

Late feedback that changes direction is the next one. Changing your mind in week two costs nothing. Changing it in month five, after four other things have been built on the earlier decision, does cost something.

And sign-off often involves more people than anyone mentioned at the start. Find out early who has to approve the work, and get them into a review rather than a summary email.

The delays that come from ours

We can underestimate how hard a connection to another system will be. The real data can turn out to be messier than the sample we were shown. And sometimes we build something that turns out to solve the wrong problem. That happens, and it's the reason we show you working versions early instead of waiting until the end.

We think the risk of a timeline running long sits better with us than with you. Our plans bill monthly rather than as a fixed project, and billing starts when the first version is live. If the work turns out to be bigger than anyone expected, that costs us weeks. You don't get a change order and an argument.

A better question to ask

"How long until it's finished?" is a less useful question than "how long until it's doing something useful for us?" The two can have very different answers. A system that takes eight months to finish can still have your dispatch team off the whiteboard in month two, and that's the date that makes a difference to your year.