What an MVP is — and what it is not

An MVP (minimum viable product) is the smallest version that lets you learn from real usage. It is not a buggy beta with every feature on the roadmap, and it is not a slide deck. The goal is evidence: do users complete the core action, return, and show willingness to pay or adopt? Everything else is negotiation with your future self.

Start with one hypothesis, not a feature wishlist

Write the riskiest assumption first. Examples: “Operations managers will replace spreadsheets if import takes under two minutes,” or “Users will link a bank account if onboarding stays under five steps.” Features exist to test that sentence. If you cannot name the assumption, you are not ready to build — you are ready to discover.

How to cut scope without cutting value

Keep the core loop: sign up, complete the main task, see the result. Defer admin polish, advanced reporting, and secondary integrations. Use manual backends where automation can wait — concierged onboarding is valid for early MVPs. Match platform to audience: B2B tools often start web-first; consumer products may need mobile early. Kapalıçarşı focused on live market practice in a virtual portfolio before layering community and gamification depth.

A practical build sequence

Week one to two: align on flows, data model, and success metrics. Weeks three onward: vertical slices — each milestone delivers a testable path, not isolated backend modules buyers cannot see. Staging environments and demo cadence keep stakeholders aligned. Launch to a small cohort before marketing spend; instrument the core events you defined upfront.

What to do after launch

Review retention, completion rates, and support tickets — not vanity downloads. Decide explicitly: pivot scope, double down on what works, or pause. Phase two should be funded by what you learned, not by the original roadmap document. Many products, including internal platforms like Fintera, began with a narrow assistant or reporting slice before broader module expansion.