Short Answer
Most custom software projects take between 8 and 20 weeks from kick-off to live, with smaller internal tools landing closer to 6 weeks and larger multi-role platforms running 6 months or more. The variable is rarely the code itself — it is the clarity of the requirements, the speed of decisions, and the number of integrations involved. A well-defined project with a single decision-maker and two integrations will move several times faster than a sprawling brief with four stakeholders and no API documentation.
What Actually Drives the Timeline
A custom software project is not one piece of work — it is roughly four phases stacked end to end. Discovery and design typically takes 1 to 3 weeks; this is where the brief becomes a set of screens, user flows, and data models. Build takes the majority of the project — usually 4 to 14 weeks depending on scope — and is where the database, backend, frontend, and integrations come together. Testing and refinement runs 1 to 2 weeks and overlaps with build. Launch and handover adds another week for deployment, training, and the first round of live support.
Inside those phases, three factors expand or compress the calendar. The first is scope clarity: a feature list with acceptance criteria is several times faster to build than a vague intention. The second is integration count: each external system (Stripe, Xero, HubSpot, a legacy database) adds discovery time, authentication work, and edge cases. The third is decision velocity: projects stall on the client side far more often than on the build side. Every day spent waiting on copy, screenshots, branding, or sign-off is a day the project does not move.
The most common surprise is that build is not the bottleneck. We have shipped 6-week projects and we have watched 12-week projects drag to 6 months — almost always because requirements changed mid-build or feedback cycles took weeks instead of days.
Why Businesses Want a Realistic Timeline
Timelines are not just about delivery dates. They feed budget approval, hiring decisions, contract start dates, and the internal commitments that depend on the system being live. An optimistic timeline that slips quietly damages trust; a realistic timeline that hits builds confidence and unlocks the next phase of work.
Businesses that get this right tend to plan in two stages. The first stage is a discovery sprint — 1 to 2 weeks — where the scope is pinned down enough to give a meaningful build estimate. The second stage is the build itself, with the timeline locked once the scope is fixed. This separation is more honest than committing to a six-month timeline before anyone has drawn a screen.
What to Look For
- Phase-by-phase estimates, not a single number. “12 weeks” is less useful than “2 weeks discovery, 8 weeks build, 2 weeks testing and launch.”
- A definition of what “done” means. Without acceptance criteria, every project drifts. Look for an agency that writes them down.
- An assumption list. Realistic timelines depend on assumptions about decision speed, content availability, and integration access. Anyone who quotes a timeline without naming them is guessing.
- A buffer for the unknowns. Integrations with poorly documented APIs, legacy data migrations, and third-party approvals (Apple App Store, payment processors) all add time that cannot be eliminated.
Common Mistakes
The most common timeline mistake is treating the agency’s estimate as fixed while leaving the client side open-ended. If the agency commits to two-day turnarounds on feedback and the client takes two weeks, the timeline will slip — and the responsibility for that slip is shared. The second common mistake is bolting on scope mid-build. Every new feature added after kick-off has a compounding effect: it pushes back its own delivery, displaces something else, and introduces re-test cycles.
How We Approach This
We scope projects in two stages so the timeline is honest rather than optimistic. A short discovery phase fixes the requirements, and the build estimate is based on what we actually know rather than what we hope is true.
Plan a Realistic Timeline
If you are weighing up a project and want a grounded view on how long it would take, the systems and services pages below outline what we build and how we structure delivery.
Disclaimer: The information provided in this article is for general guidance only and does not override or replace any terms in your contract. While we aim to offer helpful insights through our Knowledge Center, the accuracy of content in this section is not guaranteed.