Versioning
Version one is not
version final.
Founders often treat version one as the only chance to get it right. It is not. Version one is a test. Version two is informed by what you learn from that test. Every version after that gets better because each is built on real evidence rather than assumptions.
Version one: the validation release
One user type, one core workflow, one value proposition. Authentication, the primary functionality, and just enough interface to be usable. The goal is not a complete product — it is a product complete enough to answer the question: does anyone want this?
Version two: the evidence-driven update
Built after 4–8 weeks of real user data from version one. Fixes the onboarding friction. Adds the feature users actually asked for — not the one you assumed they wanted. Improves the core loop. This version is better because it is informed by behaviour, not instinct.
Version three: commercial maturity
Pricing optimisation. Secondary user types. Admin tools. Integrations. The product starts to feel like a platform. Every addition is justified by data from the previous version. No feature is added on a hunch.
The discipline: each version earns the next
Version two only happens if version one validates the idea. Version three only happens if version two shows growth. This discipline protects founders from spending £200,000 on a product that should have been abandoned at £16,000.
The version one checklist
What belongs in
version one.
If you are unsure whether a feature belongs in version one, apply this test: can users validate the idea without it? If yes, it is version two.
01
Authentication
Sign up, login, password recovery, session management. Every version one needs this. Users must have accounts so you can track behaviour, measure retention, and communicate with them.
02
The core workflow
The single most important action a user takes — the one that delivers value. For a SaaS tool, it might be creating and sending an invoice. For a marketplace, it might be posting a listing. This is the reason the product exists.
03
Just enough interface
Clean, functional, not beautiful. The interface should guide users through the core workflow without confusion. Responsive design. Consistent components. No visual polish beyond what is needed for clarity.
04
Payment flow (if applicable)
If your product charges users, version one includes the payment flow. Not as an afterthought — as a core part of the product. Stripe integration, subscription management, receipts. Validating willingness to pay is the point.
05
Success measurement
Analytics or tracking that tells you whether the product is working. Signup rates, activation rates, core action completion, retention. You cannot improve what you do not measure.
Defer list
What waits for version two.
These are the features that founders most commonly want in version one but should defer until version two. Every one of them is a good idea — just not yet.
- Admin dashboard — you can manage the product through the database or a simple admin page. A full admin panel is a version two feature.
- Analytics dashboard — use a third-party tool (PostHog, Mixpanel, simple event tracking) for version one. A custom dashboard is version two.
- Email notifications — transactional emails (password reset, welcome) are version one. Marketing emails, digests, and notification preferences are version two.
- Multiple user types — version one serves one user type. The second user type (admin, team member, second side of marketplace) is version two.
- Third-party integrations — unless the integration is core to the value proposition, it waits. Zapier, CRM syncs, calendar integrations are version two.
- Internationalisation — one language, one currency, one market. Multi-language and multi-currency are version two (or three).
- Advanced search and filtering — basic search is version one. Faceted filters, saved searches, and sorting options are version two.
- Social features — comments, messaging, activity feeds, sharing. These are engagement features that matter after you have users, not before.
Timeline
Version timeline — how long each takes.
- Version one: 8 weeks — the MVP. Scoping, design, development, launch. Fixed price from £16,000 at Wall & Fifth.
- Data collection: 4–8 weeks after launch — collect user behaviour data before deciding what version two includes.
- Version two: 4–8 weeks — informed by real data. Fixes the biggest friction points and adds the highest-impact features.
- Version three: 4–8 weeks — commercial maturity. Pricing optimisation, secondary users, admin tools, integrations.
- Ongoing: monthly sprints — continuous improvement based on metrics. Each sprint addresses the highest-impact opportunity.
The key insight: each version is smaller and faster than the last because the decisions are better. Version one is the most difficult because you are working from assumptions. Every version after that works from evidence. See our timeline guide for more detail.
Pitfalls
Versioning mistakes that cost founders money.
- Treating version one as the final product — it is a test, not a showcase. Ship it, learn from it, improve it.
- No clear boundary between versions — without an explicit scope boundary, version one grows until it is version three. Use an out-of-scope list.
- Skipping the data collection phase — launching version one and immediately building version two without measuring what happened. The data is the whole point.
- Adding features nobody asked for — version two should be driven by user behaviour, not founder assumptions. Build what the data says, not what you wish users wanted.
- Rebuilding instead of extending — if version one was built properly, version two extends it. If you find yourself rewriting the core for version two, the tech decisions in version one were wrong.
FAQ
Questions people usually have before the next step feels obvious.
What is an MVP version?
The first release — version one — built to validate the core idea with real users. Only the features needed to test whether users want the product.
What should version one include?
One user type, one workflow, authentication, minimal interface, payment flow if applicable, and success measurement.
How do you decide version one vs version two?
If users can validate the idea without a feature, it is version two. The test is: does removing this feature prevent the core validation?
How long should each version take?
Version one: 8 weeks. Version two: 4–8 weeks. Each version gets faster because decisions are informed by real data.
Related pages
Version one
Define your version one.
Build it in 8 weeks.
Tell us what you are building. We will help you draw the line between version one and version two — then deliver version one at a fixed price.