Build the MVP First
One job, one process, SQLite — and what you leave for the version after people actually book.
Learning objectives
- Define an MVP as the smallest version a real visitor can finish
- Name a simple stack: single-page app, one process, SQLite
- List what you postpone until someone has actually booked a class
The first version has one job
Workshop Co. does not need a platform. They need a page where a student can reserve Thursday pottery, and a page where the owner can see that reservation tomorrow morning. That is the MVP. Everything else — payments, reminder emails, a second location, a native app — is a later version you earn by watching the first one get used.
AI coding tools are bad at this cut. You describe “a booking site” and the model reaches for the stack it has seen in tutorials: accounts, Postgres, Docker, Redis, a payment provider. Those are real tools. They are not the first tools. Each one is another program that has to stay running before a single student has booked anything.
Ship the reservation. Learn what the studio actually does — how many seats, how often the owner logs in, how big the list gets. Then change the stack. The MVP is how you find out. It is not a prototype you throw away if the database is ordinary SQL.
A simple stack that can go live
One shell. Class list, reserve form, owner view. Built once, served as static files.
A small Node, PHP, or Python program. A handful of routes: list classes, create a booking, list bookings for the owner.
studio.db on the server disk. Tables for classes and bookings. The one process opens it.
That is four layers with almost no extra software. The single-page app is the frontend. The process is the backend. SQLite is the database — a file, not a second server. The host is one small machine with a disk that survives a reboot, a domain, and HTTPS.
SQLite fits this MVP because the studio has one site and a few dozen students. Readers and a single writer share the file comfortably. You back it up by copying studio.db (or using SQLite’s own backup command) onto another disk. You outgrow it when a second copy of the app must write at the same time, or when “database is locked” shows up during a real signup rush. That is the moment for Postgres. It is not the moment you invent the class list.
What waits
| In the MVP | After people book |
|---|---|
| Public class list and a reserve button | Card payments, coupons, packages of classes |
| Owner login, one account | Accounts for every student, password reset mail |
| SQLite file on one server | Postgres, a second app server, replicas |
| The seat check in the API, against the file | Redis, queues, a cache in front of the list |
| A single-page app on the same host as the API | A separate frontend host, a CDN, a mobile client |
If the generated repo already has Postgres, Docker, and three services, you do not have to deploy that shape to learn. Tell the tool: one single-page app, one server file, SQLite, no Docker, no payments. Read the folder again. If studio.db is the only database and there is one process to start, you have an MVP.
Worked cut — Workshop Co.
The weekend generate produced Next.js, Prisma, and Postgres. The owner has twelve classes and about forty students. The MVP cut is:
- Keep the class list and the reserve button. Drop the payment screen the model added “for later.”
- Keep one admin password. Drop public signup.
- Point Prisma, or a few SQL statements, at
sqliteinstead ofpostgresql. Same tables. - Run one process on one small server. Copy
studio.dbnightly.
When forty students becomes four hundred, or the owner wants the site up while you deploy a second copy, you move the same tables to Postgres. The product does not start over. The host gets a database server beside the app.
Draw the line
A generated booking app includes: a class list, reserve, owner login, Stripe, email reminders, Redis, Postgres, and a Docker Compose file with four services. Which three stay in the MVP, and which do you tell the tool to remove until a real student has booked?
Answer
Stay: the class list, the reserve action, and the owner login. Those are the job.
Remove for now: Stripe, reminder email, Redis, Postgres, and the four-service Compose file. Replace Postgres with a SQLite file the one process opens. You add payments and a database server after the list is in use and you know the volume. Shipping the Compose file first teaches you Docker. It does not teach you whether the studio needed a booking page.