How long does it take to build custom software?

Ask how long a build takes and you will usually hear "four to twelve months." That number is not wrong, it is just answering a different question: it describes enterprise software with committees, procurement cycles, and dozens of stakeholders. If what you need is a system that replaces a spreadsheet, connects two tools, or gets a process out of WhatsApp, the honest answer is weeks, not quarters. Below is how those weeks are actually spent.

What are the phases of a custom software project, and how long is each?

Every honest build runs through the same five phases. The durations below are for a focused single-workflow system, the most common thing a growing business actually commissions.

Phase	Typical duration	What actually happens
Discovery and scoping	3 to 7 days	Mapping how the work flows today, deciding what the software will and will not do, and fixing the scope in writing before anyone quotes a price.
Solution design	3 to 10 days	Data model, screens, and the sequence of the build. This is where the expensive mistakes get caught, while they are still cheap.
Build	2 to 4 weeks	The actual construction, shipped in reviewable pieces rather than revealed at the end.
Data migration and testing	3 to 7 days	Moving real records across, then reconciling counts and spot-checking against the source. Skipping this is how launches go wrong.
Handover and training	2 to 5 days	Documentation, credentials, and walking the team through it, so nobody is dependent on us to operate their own system.

Those phases overlap in practice, which is why a four to six week total is realistic rather than optimistic. Testing begins while the last screens are still being built, and training material gets written during the build rather than after it.

Why do software projects take longer than quoted?

Here is the part vendors rarely say out loud: on the projects that slip, the delay is almost never the engineering. It is decision latency. A build waits on a client answer about how an exception should be handled, or on sign-off from someone who is travelling, or on data that has to be extracted from a system only one person can access. A team can ship a fortnight of work in a fortnight. It cannot ship the week it spent waiting for an answer to a question nobody owned.

On the projects that slip, the delay is almost never the engineering. It is the week spent waiting for an answer to a question nobody owned.

The five things that genuinely extend a timeline, in the order they cause trouble:

• Unclear scope at the start. A project that begins before anyone has decided what it does will discover its requirements mid-build, at the worst possible exchange rate. This is exactly what a solution design audit exists to prevent.
• Slow feedback loops. A review that takes a week instead of a day adds a week, every time it happens. Naming one decision-maker at kickoff does more for a timeline than any technology choice.
• Integrations with old systems. Connecting to a modern service with a documented API is quick. Wiring into an ageing system with no API can cost more than the rest of the build combined, which is why systems that do not talk to each other are worth mapping before you commit to a date.
• Messy source data. Migration time is a function of how clean the existing records are, not how many there are. Ten thousand consistent rows move faster than five hundred inconsistent ones.
• Scope added mid-flight. "While we are at it" is how a five-week build becomes a five-month one. Ship the first version, then improve it deliberately in a second phase.

Can a custom software timeline be compressed safely?

Yes, but only in one direction: by cutting scope, never by cutting testing or handover. The safe compressions are to reduce the first release to the single workflow that hurts most, to run the new system in parallel with the old one so there is no risky launch date to hit, and to fix the scope in writing up front so no week is lost renegotiating what was meant. The unsafe compressions are skipping data verification, skipping documentation, and shortening the review of migrated records. Each of those buys a few days and costs considerably more later.

This is why we sell fixed-scope work with the duration stated up front rather than an open-ended day rate. An automation sprint runs 2 to 3 weeks, a website modernisation 3 to 5 weeks, and replacing a spreadsheet with a proper system 4 to 6 weeks. A duration you can plan around is worth more than an optimistic one you cannot.

How long does a legacy migration or website replatform take?

A content site with its integrations and search rankings carried over is typically 3 to 5 weeks. The page count matters far less than the amount of custom logic and the number of connected systems. The part that must not be rushed is the redirect and testing work, because that is where migrations quietly destroy years of earned search traffic, as we set out in whether migrating your website hurts your Google rankings. When a UK real-estate firm came to us with an ageing .NET site, the replatform to a modern platform with the CRM integration preserved was live within a month, with the old site kept running until the new one was proven. The details are in our case studies.

Does AI make software faster to build in 2026?

It genuinely helps with the construction, and it does very little for the parts that actually set the calendar. Writing code faster does not shorten the discovery conversation, does not make a client decide sooner, does not clean up the source data, and does not remove the need to verify a migration. So the build phase compresses somewhat while the surrounding phases hold. Anyone quoting a dramatically shorter timeline on the strength of AI tooling alone is quoting the easy half of the project and staying quiet about the half that runs late.

What should you ask a vendor about their timeline?

Four questions separate a real estimate from a hopeful one. What are the phases, and how long is each? What decisions do you need from me, and by when? What happens to the date if I am slow to respond? And what is explicitly out of scope for this version? A firm that answers all four in plain terms is estimating. A firm that gives a single number with no phases behind it is guessing, which is one of the patterns worth watching for in how to choose a software development partner. There are more answers of this kind in our FAQ.

The honest summary

For a focused business system, plan on four to six weeks from kickoff to a team using it in earnest, with a week of that spent before any code is written. For a legacy website migration, three to five weeks. For a multi-workflow platform, months rather than weeks, and worth scoping in phases so something useful ships early. Whatever the number, treat the timeline as a shared commitment rather than a vendor promise: the fastest projects we have run were fast because the client answered questions quickly and held the scope, not because anyone typed faster. Cost follows the same logic, which we covered in how much custom software costs and why nobody gives a straight number.