A timeline for a web application is not a single date pulled from a formula. It is a sequence of dependent phases, each with its own unknowns, and the accuracy of the overall schedule depends almost entirely on how well those phases are understood before work begins.
The first distinction to draw is between effort and calendar time. A piece of work might require 200 hours of focused development. That does not translate directly to five weeks, because the people doing the work are also handling other commitments, attending meetings, waiting for your feedback, and dealing with technical surprises. A supplier quoting effort hours is telling you about the size of the task. A timeline converts that effort into real weeks and months on a calendar, and that conversion is where most schedules break down.
Build the timeline from dependencies
| Area | Timing question |
|---|---|
| Decisions | Who must approve scope, design, data and acceptance, and how quickly can they respond? |
| Supplier capacity | When are the required people actually available? |
| Dependencies | When will data, environments, third-party access and external approvals be ready? |
| Verification | How much time is reserved for testing, fixes, retesting and business acceptance? |
| Launch | What training, migration, communications, support and rollback preparation is required? |
The phases that consume time
Most web application projects move through the same broad stages, even if the names differ between suppliers:
- Discovery and requirements: Mapping processes, defining roles, agreeing on data structures and integration points. The less defined these are at the start, the longer this phase takes — and the more it will reveal work that was not originally visible.
- Design and specification: Producing wireframes, interface designs, and a technical specification detailed enough for a developer to build from without guessing.
- Development: Building the application itself, including the database, business logic, interfaces, and integrations.
- Testing and fixing: Internal quality checks, then user acceptance testing with your team, then fixing the issues that testing surfaces.
- Deployment and handover: Moving the application to a live environment, migrating data, configuring access, and transferring operational knowledge.
Each phase has inputs and outputs. Development cannot start reliably until the specification is agreed. User acceptance testing cannot start until a stable build is available. If any phase delivers incomplete or ambiguous outputs, the next phase either stalls or proceeds on assumptions that later have to be corrected.
Why different suppliers give different timelines
When you send the same brief to three suppliers and receive timelines of three months, five months and eight months, the difference is rarely about competence. It usually reflects different assumptions about what the brief means. One supplier may be assuming a simplified version of the workflow. Another may be including integration work that a third expects you to handle separately. Some timelines include discovery; others assume it has already happened.
Until you understand what a timeline includes and excludes, you cannot compare one quote with another. The number of weeks is meaningless without the scope that sits behind it.
The shape of a timeline changes depending on what you are building and what already exists in your business.
Greenfield applications
A new application built from scratch, with no legacy data to migrate and no existing systems to integrate with, has the most predictable timeline — provided the requirements are clear. The main variables are the depth of the specification and the number of feedback rounds during design and testing. If your team is available to review designs within a day or two and test features promptly, the schedule holds reasonably well. If reviews take two weeks each, the timeline extends regardless of how fast the development team works.
Applications with integrations
When your web application needs to exchange data with existing systems — an accounting package, a stock management platform, a third-party API — the timeline depends on factors outside your supplier's control. The integration may require documentation that does not exist, access credentials that take weeks to obtain, or data formats that need negotiation with the other system's owner. A realistic timeline for an integrated application includes a specific allowance for these external dependencies, not just the technical work of connecting the systems.
Legacy replacement projects
Replacing an existing system introduces data migration and parallel-running concerns. Data has to be extracted, cleaned, transformed and loaded into the new application. The new application then needs to produce the same outputs — reports, exports, notifications — that the old system generated, so your operations do not lose capability during the switch. These projects almost always reveal hidden requirements that were never documented in the original system. A timeline that does not include a discovery phase specifically aimed at the legacy system is likely to be optimistic.
Internal tools and portals
Customer portals and internal admin tools can appear straightforward because the user base is smaller and the workflows seem simple. The timeline risk here is usually underestimating the number of edge cases: permission variations between different user types, exception handling in document workflows, or the reporting needs that only emerge once users see the first version. These projects benefit from an initial build that covers the core workflow, followed by a defined period for refinement based on real usage.
The feedback bottleneck
In almost every project type, the most common cause of timeline slippage is not slow development — it is slow decision-making on the buyer's side. If your team cannot review wireframes, test features, or answer clarification questions within a few working days, the development team either waits or proceeds on assumptions. Both outcomes damage the schedule. A realistic timeline accounts for your own availability, not just your supplier's.
Compressing testing to hit a deadline
When a project starts to run late, the phase most often squeezed is testing. This is counterproductive. Skipping or rushing testing does not make the application ready sooner; it moves the discovery of defects from a controlled testing phase into live operation, where fixing them is slower, more disruptive and more expensive. A timeline that allocates less than 15–20% of the total project duration to testing and fixing is likely underestimating the work involved. (These figures are illustrative; the right proportion depends on the complexity and criticality of the application.)
Assuming more people means proportionally less time
Adding developers to a late project does not reliably speed it up. Coordination overhead increases, onboarding new people to an existing codebase takes time, and some tasks cannot be parallelised — one person's output may be another's input. A supplier offering to double the team to halve the timeline is making an assumption that should be questioned directly.
Fixing a launch date before understanding scope
Choosing a go-live date before discovery and specification are complete is common in business planning, but it creates pressure to cut scope, skip testing, or accept an incomplete build. If you have a fixed date, the honest conversation to have with your supplier is: "Given this date, what can we realistically deliver?" rather than "Can you deliver the full scope by this date?" The former produces a credible plan. The latter produces a confident nod followed by a missed deadline.
Not distinguishing between delivery milestones
A timeline should make clear what each milestone means. "Delivery" might mean a working version on a test server, or it might mean a live system with data migrated and users trained. "Completion" might mean all features built, or all acceptance criteria signed off. Ask your supplier to define each milestone in terms of what you will be able to do at that point, not just what they will have built.
Key questions to put to a supplier
- What phases does this timeline include, and what sits outside it?
- Which parts of the timeline depend on decisions or inputs from our team?
- How have you accounted for integration work, data migration and environment setup?
- What happens to the schedule if testing reveals significant issues?
- Is there a buffer built in, and how is it distributed across phases?
- What does each milestone mean in terms of what we can see and test?
Limitations of any timeline
No timeline for a non-trivial web application will be perfectly accurate. The purpose of setting a realistic timeline is not to predict the future exactly, but to create a shared understanding between you and your supplier about the sequence of work, the dependencies between phases, and the points where decisions from your side are needed. A timeline that is honest about its uncertainties is more useful than one that presents a single date with false confidence.
If a supplier's timeline has no caveats, no conditional paths and no allowance for discovery findings, it has almost certainly been produced to win the work rather than to manage it. The realistic timeline is the one that explains what could change and what the plan does if it does.
A credible timeline should show
- Milestones tied to evidence or accepted outcomes.
- Dependencies and decision dates, not only development tasks.
- Contingency for identified uncertainty.
- A realistic period for user review and defect correction.
- The launch-readiness work that continues after coding is substantially complete.