“How long will it take?” is the first question most clients ask and the one developers are most likely to get wrong. Not because they’re dishonest — because scope is almost always underestimated at the start, and the gap between what a client imagines and what actually needs to be built is usually significant.
Here’s how I think about timelines honestly, based on what projects actually take — not what sounds good in a proposal.
The Variables That Drive Timeline More Than Anything Else
Two projects that sound identical on the surface can differ by three months in build time. The variables that matter most aren’t features — they’re decisions.
Design starting point. Building from a finished Figma file is faster than designing and building simultaneously. If you arrive with no design, add two to four weeks minimum.
Third-party integrations. Every external API — payment processing, identity providers, CRMs, shipping APIs — adds time. Not because they’re hard, but because documentation is always incomplete and edge cases always appear.
Authentication and user roles. Simple login is fast. Multi-role permission systems with organization hierarchies and granular access control add one to three weeks depending on complexity.
Your availability. Feedback cycles are usually the biggest hidden timeline killer. A client who takes a week to review each deliverable will double the calendar time of a project even if the actual build hours are identical.
Realistic Timelines by Project Type
| Project Type | Build Time | What’s Included |
|---|---|---|
| Landing page / marketing site | 1–2 weeks | Design, copywriting excluded |
| Simple web app (MVP, single user type) | 4–8 weeks | Auth, core features, basic admin |
| Multi-role SaaS application | 10–16 weeks | Roles, billing, onboarding, dashboard |
| Marketplace or two-sided platform | 16–24 weeks | Dual user flows, payments, trust features |
| AI-integrated application | Add 3–6 weeks | Depends on model complexity and data pipeline |
| API development (standalone) | 2–5 weeks | Endpoints, auth, documentation, testing |
These assume a single senior developer working full-time on your project. Part-time engagement stretches calendar time proportionally — a 6-week build at half capacity takes 10–12 weeks on the calendar.
Where Projects Actually Slow Down
In my experience, delays almost never come from the hardest technical problems. They come from a handful of predictable places.
Scope additions mid-build. A feature that seems small (“can we also add X?”) often touches the data model, the API layer, and the frontend simultaneously. One addition can add a week. Three additions in month two is a common pattern that pushes a 10-week project to 16.
Undocumented third-party APIs. Payment providers, SMS platforms, and identity services all have gaps between their documentation and their actual behavior. Budget extra time any time a third-party integration is involved.
Feedback that changes direction. There’s a difference between refinement feedback (“make the button larger”) and directional feedback (“we want to rethink this whole flow”). The latter restarts work. It happens — but it has a timeline cost that needs to be acknowledged explicitly.
Infrastructure decisions made too late. Hosting, deployment pipeline, environment setup — these feel like final steps but blocking them until the end creates last-minute pressure. I set these up in week one.
What a Realistic Project Phase Looks Like
For a mid-complexity web app — say, a client portal with authentication, a dashboard, document uploads, and an admin panel — here’s how the time actually distributes:
| Phase | Duration | What Happens |
|---|---|---|
| Discovery & architecture | 1 week | Requirements, data model, tech stack decisions |
| Design (if needed) | 2–3 weeks | Wireframes, UI design, client review |
| Backend development | 3–4 weeks | API, database, auth, integrations |
| Frontend development | 3–4 weeks | UI build, connected to backend |
| Testing & QA | 1–2 weeks | Bug fixes, edge cases, cross-browser |
| Deployment & handoff | 3–5 days | Production setup, documentation |
Total: 10–15 weeks. That’s the honest number for that scope, not six weeks because it sounded better in the sales call.
How to Shorten Your Timeline Without Cutting Corners
The fastest builds I’ve done shared three things: a clear spec before development started, design completed before the first line of code, and a client who reviewed and responded within 24–48 hours.
You can also narrow scope deliberately. An MVP doesn’t need every feature — it needs the core loop that proves the product works. Cut anything that doesn’t directly validate your main assumption. You can build the rest after.
Starting with a technical discovery engagement — one to two weeks to map requirements, define the data model, and produce a detailed spec — also reduces surprises mid-build significantly. It costs $1,500–$3,000 upfront and typically saves more than that in avoided scope changes.
If you have a project in mind and want an honest timeline estimate based on your actual scope — not a number designed to win the contract — let’s talk.