Ask ten agencies how long your project will take and you will get ten different answers, most of them optimistic. The honest answer is that timelines are far more predictable than the industry pretends, and the things that blow them out are almost never the code. After the recent guides on funding a software project in Ireland and what software actually costs here, this is the third question every founder asks before signing anything: when will it be live?
TL;DR
- Realistic 2026 bands: brochure site 2 to 4 weeks, professional SME site 4 to 8 weeks, integrated business platform 3 to 5 months, custom SaaS MVP 4 to 7 months from kick-off to production.
- AI has not collapsed delivery timelines. DORA’s 2025 research puts throughput gains at 2 to 18 per cent, with instability rising when review capacity does not scale alongside code output.
- The critical path is rarely development. Decision latency, content, third-party integrations, and access to systems are what actually add weeks.
- Client-side response time is the single biggest variable a client controls. A 48-hour feedback SLA routinely saves three to four weeks on a two-month build.
- Beware any fixed date quoted before discovery. A timeline without a defined scope is a sales artefact, not a plan.
Honest timelines by project type
These are working bands from real delivery, measured from kick-off to production launch, assuming a responsive client and no mid-project pivot.
Template or brochure site: 2 to 4 weeks. Five to ten pages on an existing theme or design system, standard contact forms, basic analytics. The build itself is days. The rest is content, revisions, and sign-off.
Professional SME site with custom design: 4 to 8 weeks. Bespoke design, a proper content model, CMS training, SEO foundations, performance work. Design and content approval consume roughly half of that window.
Integrated business site or ecommerce: 3 to 5 months. Payments, inventory or CRM integration, user accounts, complex catalogue logic. Integration testing alone is typically three to four weeks, and it is the phase most commonly under-budgeted.
Custom SaaS MVP: 4 to 7 months. Multi-tenancy, authentication and authorisation, billing, an admin surface, and a deployment pipeline that will survive contact with real users. Anything promising a genuine SaaS product in six weeks is describing a prototype, not a product.
Legacy modernisation: 6 months and up. Almost entirely dependent on how well the existing system is understood. Undocumented business logic is the single largest source of variance in our estimates.
Why AI has not halved your timeline
This is the uncomfortable part of the 2026 conversation. Code generation is genuinely faster. Delivery is not, at least not proportionally.
DORA’s 2025 State of AI-assisted Software Development found that around 89 per cent of organisations now use AI in their workflow, with throughput improvements landing between 2 and 18 per cent. Not 50 per cent. Not 10x. Meanwhile, instability rose in teams that scaled code output without scaling review, testing, and observability alongside it.
The mechanism is simple enough. If writing code was 40 per cent of the effort on a project and you make that portion twice as fast, you have removed 20 per cent of the total, not half. And you have added review load, because generated code still needs someone who understands the domain to verify it. We covered this dynamic in depth in our piece on the verification bottleneck.
Where AI genuinely compresses schedules is narrower and worth naming: rapid prototyping during discovery, comprehension of unfamiliar legacy code, mechanical migrations, test scaffolding, and documentation. Those are real savings. They are not a licence to promise a three-week SaaS build.
The critical path is almost never code
When a project slips, it is worth auditing what actually caused it. In our experience, the recurring culprits are consistent.
Decision latency. A question that waits four days for an answer costs four days, and it usually blocks more than one workstream. On a two-month build, three or four of these compounds into a fortnight.
Content. The most reliably underestimated dependency in web projects. Copy, product photography, legal pages, and translations are client-owned and rarely started early enough. Development finishes and the site sits waiting for an About page.
Third-party access. Payment gateway approval, bank verification, API keys from an incumbent vendor with no incentive to help, DNS controlled by whoever built the last site. These are administrative, not technical, and they are ruthless on schedules.
Integration reality. The vendor’s documentation says one thing, the sandbox behaves differently, and the production environment has a rate limit nobody mentioned. Budget contingency here, always.
Scope drift. Not the big obvious pivots, which everyone notices and reprices. The small ones: a field here, a report there, an extra user role. Each is trivially defensible and collectively they are why projects run 30 to 40 per cent over.
What actually compresses a timeline
Four levers, in rough order of impact.
Do discovery properly. It feels like the opposite of speed. It is not. Building the wrong thing is the most expensive delay available, and a defined scope removes the mid-project rework that eats whole sprints.
Commit to a feedback SLA. Agree 48 hours for standard reviews and name a single decision-maker with actual authority. Design by committee is measured in weeks, not opinions.
Start content on day one. Not at the design review. Not when staging is ready. Day one, in parallel with everything else.
Ship in phases. A phased launch gets a working, valuable subset in front of users while later phases are still in development. It also surfaces the assumptions that were wrong while there is still budget to correct them. Practically every project we deliver is structured this way, and it is the closest thing to a free timeline reduction that exists.
Reading a proposed timeline critically
Five things worth challenging in any proposal you receive.
- A fixed launch date quoted before discovery. Nobody can responsibly commit to a date before the scope exists. If they have, the date will move or the scope will quietly shrink.
- No named client dependencies. A credible plan states what it needs from you and by when. A plan with no client obligations has hidden them, and they will surface as your fault later.
- Zero contingency. Every schedule should carry buffer, typically 15 to 20 per cent. A plan with none is a plan that has never survived an integration.
- Testing compressed into the final week. QA is not a phase you bolt on. If it appears as a three-day block at the end, it will be the first thing sacrificed.
- Suspiciously fast because AI. Ask specifically which phases the acceleration applies to. A good answer names prototyping and migration work. A bad answer is a vague gesture at velocity.
How we approach it
At REPTILEHAUS we quote timelines in ranges, not single dates, and we separate discovery from delivery so the range narrows once the scope is genuinely known. Discovery is fixed-price and fixed-duration. Delivery is phased, with the dependencies we need from you written into the plan alongside the work we owe you.
It is a less impressive-sounding proposal than a confident single date. It is considerably more likely to be true, and it means the conversation at week six is about the product rather than about the schedule.
Planning a build and want a realistic timeline before you commit budget? Get in touch, and we will walk you through what your specific scope actually implies.
📷 Photo by Eric Rothermel on Unsplash
