useful project timeline is not a single number pulled from a feature list. It is a sequence of decisions, dependencies and review windows. A focused marketing site can move quickly because it has fewer states and integrations. A customer portal or native app usually needs accounts, data, permissions, testing and launch work that cannot all happen at once. The honest answer begins by identifying which kind of product you are actually building.
Thecalendarisusuallyshapedasmuchbydecisionsandcontentasitisbycode.
Discovery turns a broad request into agreed users, journeys, features and exclusions. Design settles structure, content hierarchy and the important interface states. Development builds the approved system and connects any services it depends on. Quality assurance covers real devices, browsers, accessibility, data, error states and performance. Launch includes production configuration, analytics, redirects or store submission, followed by checks once real traffic arrives.
- Discovery: agree the problem, users, success measures, scope and dependencies.
- Design and content: approve structure, copy, visual direction and important states.
- Development: build in working increments and review them before the whole product is finished.
- Quality assurance: test devices, browsers, accessibility, integrations, permissions and failure paths.
- Launch: configure production, migrate content or data, submit to stores where relevant, and verify the live result.
The most common delays are unresolved content, access to third-party systems, decisions that need several stakeholders, and features whose rules only become clear after somebody sees them working. Integrations deserve particular care: an API may exist without supporting the exact workflow the product needs. App Store enrolment, legal review, data migration and procurement can also sit outside the development team's control.
- Content or brand assets that do not yet exist.
- Multiple approval layers without one final decision-maker.
- Legacy data that needs cleaning before it can be migrated.
- External APIs, payment providers or identity systems that are not ready.
- New requirements introduced after design or development has been approved.
- App Store, security, legal or accessibility reviews with their own lead times.
Ask for a timeline with assumptions and decision dates, not just a launch date. It should say what the client must provide, when feedback is due, which work can run in parallel and what happens when scope changes. A range is more credible than a false day-perfect promise at the start. Once discovery has removed the largest unknowns, that range should narrow into dated milestones.
Leave room for production verification, measurement and small corrections after launch. Websites need redirects, tracking and form delivery checked in the real environment. Apps need review time and may need a response to App Review. A serious plan also identifies the first post-launch decision: what evidence will determine the next improvement, rather than immediately beginning another unprioritised feature list.
A focused website can often move quickly once positioning, pages, copy and approvals are ready. Delays usually concentrate in content, stakeholder review, legacy migration and integrations. An iOS application adds product-state design, backend and device testing, signing, store materials and App Review. The calendar should expose those dependencies rather than hiding them inside one delivery date.
- Website critical path: discovery → information architecture → design system → page build → content population → responsive and accessibility QA → DNS launch.
- iOS critical path: product discovery → risky prototype → interface and data architecture → feature slices → device and failure-state QA → App Store Connect → review and release.
- Shared dependency: fast, empowered feedback. A three-day review window repeated ten times can add a month without any engineering delay.
Ask for a range with assumptions, not a false exact date. The plan should identify client decisions, third-party approvals, content deadlines, test devices, store review contingency and what is deliberately deferred from version one.