MVP Development

The purpose of an MVP is to buy information as cheaply as possible. So the question is not what your product should eventually do, but which single assumption would sink the business if it turned out to be wrong. Build the smallest thing that tests that, put it in front of real users, and let their behaviour decide what comes next.

This is harder than it sounds, because the instinct is to build what feels complete. Settings screens, admin panels, analytics dashboards and onboarding flows all feel like progress and prove nothing about whether anyone wants the product. We have watched more runway disappear into premature admin tooling than into any other category of work.

A focused MVP is typically four to eight weeks: three days scoping, a week prototyping, three to six weeks of build, and a few days to deploy and iterate. You get a working product on real infrastructure with real accounts, plus a tech roadmap for the version that follows. Everything is registered to you from the start — repository, hosting, domain, third-party accounts — so if you raise and hire, your team inherits it without a negotiation.

Both of our internal SaaS products started this way. The school management portal began as the modules one preschool actually needed; the restaurant POS began as order booking and a kitchen queue. Each earned its later scope by being used.