The second question every founder asks — right after "what will it cost?" — is "how long?" And the honest answer has changed more in the last two years than in the previous ten. Here's the 2026 calendar, phase by phase, and the things that actually blow schedules (spoiler: it's almost never the code).
The short answer
- Template / no-code build — 1–3 weeks. Fine for validating demand.
- Focused MVP (one platform, a few core flows) — 4–8 weeks with a small AI-native team; 3–6 months at a traditional agency.
- Mid-size product (accounts, payments, admin, real backend) — 2–4 months.
- Complex or regulated (marketplaces, health/fintech, heavy real-time) — 6 months and up, mostly for reasons that aren't engineering.
Where the weeks actually go
A well-run fixed-scope build spends its calendar roughly like this:
- Discovery & product definition — about a week. What it is, who it's for, which screens matter. We compress this into a five-line brief; vague projects spend a month here without noticing.
- Design — 1–2 weeks. Running ahead of the build, never far ahead. Waiting for a 60-page design phase to "finish" before coding starts is how agencies turn six weeks into six months.
- Build — 3–6 weeks. The part AI actually compressed. Boilerplate, wiring, tests, and the tenth CRUD screen used to be most of the invoice; now a small senior team moves through them 2–5× faster.
- Hardening — 1–2 weeks. Real devices, bad networks, empty states, that one Android keyboard. AI does not do this for you; skipping it is how you meet your users through one-star reviews.
- Launch logistics — days, plus a buffer. App Store review usually clears in a day or two now, but first submissions bounce often enough that you should hold a one-to-two-week buffer before any public date.
What actually blows the schedule
After enough builds, you learn the calendar killers by name — and none of them are typing speed:
- Unclear scope. "It's basically Uber" hides forty decisions. Every one surfaces mid-build as a week of rework.
- Decision latency. The team asks a question Tuesday; the answer arrives the following Thursday. Multiply by twenty questions and there's your month.
- Scope creep. Each "small addition" costs its build time plus re-testing everything it touches.
- Third parties. That payment provider's sandbox, that partner API's approval queue — schedule around them early or they schedule you.
Apps don't ship late because the code was slow. They ship late because nobody could say no.
How to keep it fast
- Write the five lines first. Idea, user, screens, brand, ship date. If it can't fit, it isn't ready to build.
- Name one decision-maker. Committees review; one person decides, same-day.
- Demand a weekly demo. Working software every week is the only honest progress report.
- Cut, don't slip. When something must give, drop scope and hold the date — a shipped v1 beats a perfect v1.2 that never arrives.
- One platform first. The second platform is a sequel, not a launch requirement.
How we run the clock
At Five Line, the ship date is literally one of the five lines — it's part of the brief, not a hope appended to it. We build in fixed-scope sprints with a demo every Friday, using the same AI-native process we use on our own apps and games, and we'd rather cut a feature than move your date.
Want a real timeline for your idea? Send us the five lines — you'll get a schedule and a fixed quote in writing, usually within two days.