How long does a bespoke software build take?

Shorter than it used to be, and still longer than the demo suggests. A working first tool is a matter of weeks once the data is to hand. A platform that runs a whole process is delivered in stages over months, each stage in use before the next starts. What stretches either one is rarely the code.

What sets the pace

Decisions. Every build has a dozen questions only you can answer: which of the three versions of the spreadsheet is the real one, whether the judge or the organiser confirms the date, what happens when a nominee withdraws. A day's turnaround on those keeps a build moving. A fortnight's turnaround can double the timeline on its own.

Data. The first week of most builds is spent getting a real export of real records and finding out what is actually in it. The sooner that export arrives, the sooner the design stops being theoretical.

Integrations. Connecting to a system with a documented API is days. Connecting to one with no export is a project in itself, and sometimes the right answer is not to connect at all.

The size of the first piece. The single biggest lever. A tool that does one job is usually live in weeks because there is less to decide, less to test and less to get wrong. A platform scoped to do everything on day one takes months before anyone can use any of it.

How much code there is to write. Last on the list on purpose. AI-assisted development has made this the fastest part. It has not changed how long it takes a team to decide what they want.

How staged delivery works

We do not build to a single launch date. The work is cut into stages, each one a working piece that goes into use before the next is scoped.

1. Understand. One or two sessions with the people who do the work, mapping where the hours go and agreeing the one number the first stage should move.
2. First stage. The smallest useful tool, built against real data, put live, and used. This is where the brief meets reality.
3. Next stages. Each one priced and scoped against what the last one taught us. A platform grows this way, one working piece at a time.
4. Hand over. Documentation, accounts in your name, and a named person to call if you want one.

The advantage is not speed for its own sake. It is that every stage is small enough to be right, and the system is in use from early on rather than at the end.

Two real timelines

A single pub. The Plough in Harborne wanted hiring, menu and market tools built around its own kitchen. The first tool, a workstyle assessment used in hiring, went live in November 2025. The menu sense-checker, the competitor monitor and the recipe database followed in the early months of 2026, each scoped, built and handed over as a working piece rather than a roadmap. Each tool went into use as it was finished.

Nine awards programmes. A national care-sector awards business runs nine programmes, each with the same annual cycle. The operations platform went into production on 1 September 2026 with one programme imported and its finalists invited, and the remaining programmes were activated in turn. The team was running a live programme on it while the others were brought across.

What to expect from a good estimate

A timeline given before anyone has seen your data is a guess. A good estimate comes after the first session, is stated per stage rather than for the whole, and names what it depends on from your side: the export, the decisions, the person who will answer questions.

Treat a fixed date for the whole build, given on the first call, with caution: nobody can have checked the five things above by then.

Where to start

Most of the time on a build is spent waiting for answers, so the fastest thing you can do costs nothing. Send the export before the first session, protect a few hours a week for whoever owns the project, and hold the first stage to its original scope until it is live. Those three decide the pace more than anything a developer does.