Lesson 5 — From Idea to a Working MVP

Hands-on · about 8 minutes.

An idea is not an application. The gap between "I want to build X" and a functioning X is where most projects fail — typically because the initial version is too large to complete. This lesson addresses that gap with a repeatable process, the same process used in the capstone.

Begin with the MVP

MVP denotes Minimum Viable Product — the smallest version of an idea that still delivers its core value. "Minimum" because all non-essential elements are removed; "viable" because the result must still function and provide value. An MVP is not an inferior product; it is a focused one.

The rationale for beginning here is that a small initial version can be completed, tested, and presented to a real user quickly. The information gained from that version then informs subsequent development. An overly large initial version tends to remain unfinished.

Practice: limiting scope

The most difficult aspect of defining an MVP is excluding features. For each feature below, assign it either to the first version or to a deferred list.

This activity needs JavaScript enabled. The lesson below still covers everything.

The build lifecycle

Once the MVP is defined, every small application follows the same seven stages. The practices from Lessons 3 and 4 appear within them.

Idea and audience

Name what you are building and who it is for. "A tip calculator, for someone splitting a restaurant bill." One sentence.

Define the MVP

Write the one core thing the first version must do. Put every other idea on a separate "later" list and set it aside.

Plan in small steps

Break the MVP into an ordered list of small, checkable steps. Each step should be something you can finish and look at.

Build with an AI assistant

Work through the steps one at a time, applying the practices from Lesson 3 — provide context, scope each request, and review the changes the assistant actually made.

Test it

Use the application directly. Does the core functionality work? Test it on a phone-sized screen. This applies the Lesson 4 verification practice to a complete application.

Iterate

Correct the issues that testing revealed, then make improvements. At this point — and not before — features are drawn from the deferred list. Each iteration is small.

Deploy it

Make the application available to a real user. An application that no one uses is not complete. Deployment is also the means by which you determine what to improve in the next iteration.

The lifecycle is iterative rather than linear: deployment and testing feed directly into the next round of iteration.

Quick check

This activity needs JavaScript enabled.

Summary: reduce the idea to its smallest viable version, build that version in small tested steps, deploy it to a real user, and use the resulting information to direct the next iteration.

← Previous: Prompting Well and Checking the Output Next: the capstone — Build a Concept Manipulative →