What a real MVP actually looks like — a worked example.

This is the list that makes an MVP work. Every item below is a good idea — just not a version one idea:

• Team features — inviting team members, shared projects, permissions. Version two, after validating that solo freelancers want the product.
• Expense tracking — logging business expenses alongside time. Useful but not on the critical path. Deferred.
• Tax calculations — VAT, tax summaries, MTD compliance. Complex, regulated, and not required to validate the invoicing hypothesis.
• Accountant access — a read-only view for the user's accountant. A version three feature at earliest.
• Reporting dashboard — charts, trends, revenue summaries. Useful for retention but not required for initial validation.
• Mobile app — the product works in mobile browsers. A native app is a separate build after web validation.
• Integrations — Xero, QuickBooks, Google Calendar, Slack. Each is a week of development. None are required for the core workflow.
• Email notifications — beyond transactional (password reset, invoice sent). Digest emails, reminders, and marketing emails are deferred.

Every feature on this list was proposed during scoping. Every one was deferred. The MVP launched on time, on budget, and validated the hypothesis in the first month.

Within the first four weeks after launch, the data told a clear story:

• Signups exceeded the target — 140 vs the 100 goal. The problem resonated.
• Activation was strong — 62% of users created a project and logged time in their first session.
• The invoice feature was the hook — users who generated an invoice in week one had 4x higher retention.
• Pricing was validated — 18% converted to paid within 30 days at the £20/month price point.
• The biggest request was expense tracking — confirming it as the right version two feature.
• Nobody asked for team features — validating the decision to defer them.

That data — real user behaviour, not survey responses — informed every decision about what to build next. The MVP had done its job. Read about scaling from MVP to full product for what comes after this point.

Your product will look different from this example. Different user, different problem, different workflow. But the principles are identical:

• One hypothesis — stated clearly before anything is built
• One user type — specific enough to design for
• One critical path — the shortest journey from signup to value
• Everything else deferred — deliberately, with an explicit out-of-scope list
• Production-grade code — built to scale, not to throw away
• Success metrics — defined before launch, measured from day one

At Wall & Fifth, we build MVPs like this every month. From £16,000, delivered in 8 weeks. Book a scoping call and tell us what you are building.