AriesDevs engineering team Engineering notes
6 min read
A minimum viable product is the smallest version of your idea that delivers real value to a real user and teaches you what to build next. It is not a bad product or a demo. The skill is in choosing what to leave out. These steps keep the scope honest.
Step 1: name one user and one job
Write one sentence: "A [specific person] uses this to [do one job] so that [outcome]." If you need the word "and" three times, you have more than one product. Pick the user who feels the problem most.
Step 2: map the shortest path to value
List every step a user takes from landing on the product to getting the outcome. Keep only what is needed for that path. Sign up, do the core action, see the result. Everything else is a candidate for version two.
Step 3: cut the features that feel important
- Advanced settings and personalisation.
- Multiple user roles, unless the product cannot work without them.
- Complex reporting. A simple export or a manual report is enough to start.
- Native apps. A responsive web app tests the idea faster and cheaper.
- Anything you can do by hand behind the scenes for the first ten customers.
Step 4: choose boring, scalable foundations
Pick well-supported tools your team already knows: a mainstream framework, a managed database, hosted authentication and payments. The MVP will change, so the goal is to make change cheap. A clean structure and automated tests matter more than clever technology.
Step 5: ship in weeks and measure
Aim for a first usable release in six to ten weeks. Decide in advance what success looks like, for example "ten users complete the core action in their first week", and add basic analytics so you can see it. Talk to every early user.
How an MVP grows without a rewrite
Keep the data model clean, separate the interface from the business logic, and write down the shortcuts you took. Because the foundations are conventional, you can add features, roles and integrations in later sprints instead of starting again. If you want help drawing the line between version one and version two, a short discovery sprint produces exactly that: a prioritised scope, a prototype and a cost range.
