Key takeaways
- Eight weeks is enough for one valuable end-to-end journey, not a compressed version of an entire roadmap.
- Start with the riskiest product assumption and define a measurable launch test.
- Demonstrate a working slice every week and cut scope when evidence threatens the deadline.
- Security, accessibility, analytics and operational ownership are launch work, not optional polish.
An eight-week launch is credible when the product tests one important assumption with a narrow group of users. It is not credible when the deadline stays fixed while the brief includes several user roles, every integration and a complete administration suite.
The schedule below assumes a small, experienced team, a decision-maker who can answer questions quickly and no procurement or compliance process with a longer lead time. Those constraints matter as much as the technology.
Before week one: make the test explicit
Write a one-sentence hypothesis: “Independent recruiters will pay to publish a vacancy if posting takes under five minutes,” for example. Name the first users, how you will reach them and the behaviour that counts as evidence. A launch without a recruitment plan often produces a working product and no learning.
- One primary user and one job they need to complete.
- A measurable action, such as posting, booking or paying.
- A target group that can be contacted before launch.
- A named product owner who can make same-day scope decisions.
Week 1: map the smallest complete journey
Interview a handful of representative users, map the current workaround and identify the step carrying the most risk. Draw the main flow from arrival to value. Keep exception cases visible, but do not automatically build all of them; some can be handled manually during the pilot.
End the week with a prioritised scope, a technical risk list and a definition of launch. If payments, identity checks or external data are essential, test those APIs now rather than discovering their limits in week six.
Week 2: prototype and choose foundations
Test a clickable prototype with target users. Watch where they hesitate instead of explaining the interface. Revise the flow, agree the visual direction and create a thin technical skeleton with deployment, authentication and the core data model.
The deliverable is not a perfect design file. It is enough validated detail for development to move without repeatedly guessing, plus a staging environment that can receive a release.
Weeks 3–5: build vertical slices
A vertical slice crosses the interface, business rules and database to complete a small real task. Build the simplest end-to-end journey first, then add depth. A marketplace might let one seller create a listing and one visitor view it before filters, saved searches or team permissions exist.
- Week 3: the core record can be created and viewed on staging.
- Week 4: the primary transaction or response works, including failure states.
- Week 5: the owner can operate the service through a minimal admin workflow.
Week 6: test the uncomfortable cases
Run the main journeys on phones, slower connections and keyboard-only navigation. Test invalid data, interrupted payments, duplicate submissions and permissions between accounts. Ask pilot users to complete tasks without coaching and record the problems by severity.
This is usually the last responsible point to change the launch scope. Fix blockers and confusing steps first. Move cosmetic wishes and low-frequency exceptions to the post-launch list.
Week 7: prepare the service, not just the screen
- Set up production, backups, error reporting and a tested rollback path.
- Write privacy terms and support guidance that match what the product actually does.
- Add analytics for the hypothesis, with a funnel from arrival to the key action.
- Import only the data needed for launch and rehearse the process.
- Invite the first users and schedule time to observe them during launch week.
Week 8: release in a controlled way
Start with a small cohort instead of announcing to everyone at once. Watch errors, support questions and the key funnel daily. Fix issues that prevent the core job; collect other requests without immediately changing direction.
| Signal | What it may mean |
|---|---|
| People start but do not finish | The flow, trust or value proposition needs work |
| People finish but do not return | The job may be infrequent or the result is not valuable enough |
| Invited users never start | Recruitment or positioning is weak; product changes may not solve it |
| Users rely on one unexpected feature | Investigate whether it points to a stronger problem to solve |
What to cut first
Cut breadth before quality. Reduce roles, integrations, settings and edge-case automation. Do not cut access control, data protection, backups, basic accessibility or monitoring. Manual operations behind the scenes are acceptable for a small pilot; unsafe handling of user data is not.
Written by the Prestigious Software team
We design, build and run web platforms, SaaS products and mobile apps. About us
Our team reviews each article. Claims based on standards or research link to primary sources; examples are illustrative unless identified as client work.
