The chart that lies
Most software project plans show a single timeline: design, build, ship. The reality is that the gap between a working prototype and a production-ready system is wider than that chart admits, and the work that lives in the gap is what determines whether the project survives its first year.
Phase 1: Discovery (1-4 weeks)
Discovery is where the project is shaped. Stakeholder interviews, workflow analysis, integration audit, technical feasibility, scope definition. Teams that skip this phase pay for it during build by rewriting features once the actual requirements surface. Properly scoped discovery saves 2-3x its duration in build time.
What takes longer than expected: getting access to existing systems and data. Three weeks of "waiting for IT to give us a read-only credential" is normal.
Phase 2: Prototype (2-4 weeks)
A prototype is the cheapest way to validate the discovery output. Build the most uncertain part of the system end-to-end. If the project depends on a specific integration working, that integration is the prototype. If it depends on a UX pattern being understandable, that screen is the prototype. The prototype is throwaway code with one goal: surface unknowns.
What takes longer than expected: edge cases discovered during the prototype that change the design.
Phase 3: Core build (8-20 weeks)
This is the visible work. Frontend, backend, mobile, database, integrations. Teams plan well for this phase because it looks like programming. The phase typically runs close to estimate when the discovery and prototype phases were thorough.
What takes longer than expected: edge cases that did not appear in the prototype, integration complications with partner systems, performance optimization for hot paths.
Phase 4: Pre-production hardening (3-6 weeks)
The phase most plans underestimate. Error handling, retry logic, observability, monitoring, alerting, load testing, security review, accessibility audit, GDPR review, backup and restore drills, deployment automation, on-call rotation setup. The system at the end of Phase 3 works on the happy path. Phase 4 makes it work on the unhappy path.
What takes longer than expected: security review (always), accessibility (often), partner SLA negotiation.
Phase 5: Pilot deployment (4-8 weeks)
Not a full launch. A pilot to a small group of real users with the team available for fast iteration. This is where the gaps between what the team built and what users actually need become visible. Expect to ship 3-5 meaningful changes during the pilot.
What takes longer than expected: usability issues that did not show up in internal testing because internal users know the workflow.
Phase 6: General availability (2-4 weeks for rollout)
The rollout itself is usually fast if Phases 4 and 5 were done right. Migration of remaining users, feature flag flips, communication to existing users, support team training, rollback plan in case of regression.
What takes longer than expected: support team training, communication to existing users (which always involves more stakeholders than expected).
Post-launch: stabilization and iteration (ongoing)
The first three months after launch include the highest rate of bug fixes, performance issues, and user feedback. Budget engineering time for this phase rather than rolling people off to new projects on launch day. Teams that move on too quickly leave the system in a fragile state.
Total realistic timeline
For a focused B2B internal tool with one integration: 4-6 months from kickoff to GA.
For a B2C mobile app with backend, two platforms, payments: 7-10 months. For an enterprise-grade system with multiple integrations and strict compliance: 10-18 months.
What shortens the timeline
Clear scope. Existing identity and infrastructure to integrate with rather than building new. Small first release with phased rollout. Senior engineers from day one rather than ramping the team up during build. A product owner who can make decisions in days rather than weeks.
What lengthens the timeline
Scope creep, especially after Phase 3 starts. Unclear regulatory requirements. Multiple stakeholders without a clear product owner. Custom design language rather than standard UI patterns. Building backend from scratch when an existing system could be extended.
The single biggest determinant
The gap between an estimated and actual timeline correlates almost perfectly with how much time was spent on discovery and prototype before the build started. Phases 1 and 2 are the highest-leverage investments in the project, and the easiest to skip when leadership wants to see immediate progress. The teams that ship close to plan are the ones that protect those early weeks.
