A useful V1 does not aim to do everything. It validates value quickly on a clean, evolvable foundation. After shipping with a dozen startups, we see the same three patterns break them : scope bloats 40% mid-flight, architecture decisions get postponed, quality gets cut for speed.
The result : a fragile demo that doesn't survive the first paying customer. Worse, it forces a complete rewrite six months later, erasing the time you supposedly saved upfront. We've watched teams "gain" 6 weeks by shipping untested code, then lose 16 weeks fixing bugs in production and refactoring a half-baked architecture. The gain was an illusion.
👉 The right goal : ship a testable, genuinely usable version, not a proof-of-concept for fundraising. The question isn't "how many features do we have ?" but "can this product handle 100 paying users without collapsing ?"
Why V1s slip (and how to stop it)
About 70% of deadline slips come from three recurring mistakes.
First, scope is never truly frozen. You start with 15 "must-haves" : auth, dashboard, CSV export, notifications, Slack integration, etc. By week 3 after internal demos, you're at 24. The co-founder wants "bulk actions," a dev suggests Zapier integration "while we're at it," a tester asks for dark mode. Week 5, you're at 32 items and the deadline is already slipping.
Second, architectural decisions drag on. Database choice ? Postgres or DynamoDB ? Backend ? Next.js API routes or Node/Express ? How to handle auth ? OAuth or custom JWT ? These should lock in week 1: they influence everything downstream. Instead, you say "we'll figure it out while coding," and by week 3 you realize you've built on the wrong foundation.
Third, quality becomes the compromise lever. To "not fall behind," you skip tests (saves time now), defer performance optimization (we'll fix it post-launch), ignore logging (too complex right now). By week 8, your product is so buggy that 50% of testers abandon it after 5 minutes. Real paying customers ? They never show up.
Teams that ship in 90 days follow three simple rules : hard scope discipline from day one, architecture decisions locked before writing a single line, and baseline quality non-negotiable (stability, acceptable performance, baseline security, logs) that's never the compromise when you're "running behind."
Week 1 : decisions to make before touching code
Spend 3-4 days aligning product, team, and tech on :
- The user problem you're solving : one sentence. "Help freelancers invoice in under 5 minutes," not "complete business management platform."
- The critical user flow : which user journey must work flawlessly ? For invoicing : sign up → add client → generate invoice → download. That's it.
- Measurable success criteria : 20 beta testers create an invoice without support in week 1. Pages load in under 2 seconds on 4G.
- Acceptable vs blocking debt : you defer "advanced PDF export" to V2, but not weak authentication.
This written, shared, validated charter saves months of debate. It becomes your Constitution : when a request comes in, you ask "does this fit our V1 scope?" and you have a clear answer.
90-day cadence : phases and real deliverables
| Weeks | Main objective | Real deliverables | Common pitfalls to avoid |
|---|---|---|---|
| 1-2 | Scoping + architecture | V1 backlog (< 50 items), DB schema, API contracts, auth method locked in | Pushing architecture decisions, starting dev without a written backlog |
| 3-5 | Build core product | Working auth + roles, end-to-end main flow locally | Adding "nice-to-haves," perfectionism on UI, skipping E2E tests |
| 6-8 | Integration + stabilization | Fully wired API, data layer live, staging deployment, first testers on the system | Ignoring small bugs (they compound), skipping perf work, no monitoring |
| 9-10 | Polish + iterative feedback | Performance optimized (< 2.5s main), 80% of critical bugs fixed, tester feedback integrated | Building without measuring impact, late-stage pivots |
| 11-12 | Production readiness | Monitoring + alerts live, deployment docs, incident runbook, controlled launch | Last-minute refactors, underestimating CI/CD work |
Every week : internal demo Monday, feedback Wednesday, decisions Thursday. Nothing lingers past 48 hours.
The foundation to build first (and why it's non-negotiable)
Weeks 3-5, build in this exact order. This order is deliberate : each block unblocks the next.
1. Auth + roles (4-5 days). User, admin (or more roles if your product requires). Auth0, Firebase, sessions, whatever. What matters : it's the foundation for everything else. Without auth, you can't test multi-user flows.
2. End-to-end main flow (7-9 days). Login to the key action : create invoice, send message, upload document, publish post. Zero polish. Just : it works end-to-end locally. A tester logs in and can perform the action and see the result.
3. Data schema + API (5-6 days). Properly structured database (migrations, foreign keys, indices where they matter). Stable API endpoints (you'll refactor in V2, but not in V1.1 because the architecture was broken). Testable locally or on staging DB.
4. Basic analytics (2-3 days). Who logs in ? What event signals conversion ? User creates invoice = "invoice_created" event. Event sent to Segment, Amplitude, or a simple webhook. You need to measure the funnel : 100 sign up, 70 add a client, 50 create an invoice. That tells you if your UX makes sense.
This foundation is 60-70% of the initial work. The remaining 30-40% (UI polish, animations, edge cases, perf tuning) happens weeks 6-12, after you've iterated on user feedback. Respect this order : too many teams build the UI first, polish micro-interactions, then discover week 6 that the main flow doesn't make sense to users.
Quality : what never gets compromised
On every piece of code :
"A fast but unstable V1 costs 4x more : disappointed users, bug reports, emergency patches, broken trust."
Critical path stability : bugs on the main flow are fixed before merging. Basic E2E tests (Playwright, Cypress) by week 4. Acceptable performance : < 2.5 sec initial load, < 1 sec interaction. Measure with Lighthouse, optimize once. Baseline security : HTTPS, input validation, no secrets in Git, basic OWASP Top 10. Logs + monitoring : every backend error logged, alerts on 500s from week 9 onward. You don't wait for V1.1.
This isn't perfectionism. This is avoiding the time bomb.
Real case : when it works
A services marketplace (cleaning, plumbing, electrical) we shipped 18 months ago. Week 1 : team of 4 (1 PO, 2 devs, 1 designer). Brutal scoping. V1 scope : 80 items initially, cut to 45 after two days of discussion. Real criteria : 20 cleaners create a profile, 20 customers send a request, 10 requests get an offer. That's it.
Weeks 2-5 : auth (Passportjs + PostgreSQL), end-to-end main flow (customer sends request → cleaner gets notified → sends offer → customer accepts or rejects). Database : simple but sound structure (users, services, requests, offers). Zero attempt to "predict everything," zero botched migrations. Week 4, first testers. Expected chaos : one major bug (notifications weren't sending), fixed in 3 hours because logs existed.
Weeks 6-8 : feedback was clear. Customers wanted to see service history, cleaners wanted to easily decline requests. Two weeks to iterate.
Weeks 9-10 : performance fully optimized, Lighthouse 90+, Core Web Vitals stable. Monitoring in place (Sentry for errors, PostHog for usage).
Week 11 : first real paid cleaning job. Week 13, 8 transactions. Week 16, 50+ weekly. V2 took 6 weeks (Stripe payments, rating system, chat between customer and cleaner) because the base was solid.
The team didn't slip. Not because they were perfect. Because : (1) scope was clear and respected, (2) tech decisions were locked from day one, (3) quality was never the compromise. Result : 18 months later, they have 150 paying cleaners, five-figure monthly revenue, and zero tech debt bomb threatening them.
Execution rhythm : how to stay on track
Sprint planning : 1-2 weeks, capped at 15-20 points. Mid-sprint scope change = never. It's yes or no. Weekly demo : 45 minutes max, internal or with stakeholders. It forces features to finish, not to drag on polish. Centralized feedback : one Slack channel, one issue tracker. Requests go there, not in DMs or email threads. They get triaged, you say "V1 or V2 ?", and it's tracked. Fast arbitration : the PO or founder decides in 15 minutes. No endless debate.
👉 Concrete result : you gain 2-3 weeks just by eliminating noise and making decisions fast.
What this actually changes for business
Shipping 12 weeks early instead of 20 means 8 extra weeks of paying customers in year one. Even if only 10-15 customers pay on day one, you learn their real needs in real time. You adjust the product quickly instead of guessing. You validate or kill your market hypothesis before burning marketing budget.
A solid V1 (not perfect, solid) lets you ship V2 in 6-8 weeks, not 12. Because you iterate on stable ground, not on broken code.
👉 In 90 days, you're not chasing perfection. You're balancing speed with durability : fast enough to learn, solid enough not to mislead users.
This framework has worked for task apps, marketplaces, B2B tools. Details change, rhythm stays. Inprogress works with teams applying exactly this system : hard scope week one, iterative delivery, measure what works.