Capstone: from prototype to product

Six weeks later

Let's take stock. Six weeks after the first line of prompt, Tom's app is used by three classes in two schools. The math teacher paid for his "classroom" plan via the Payment Link. Lina sports a 34-day streak. And this week Tom received four messages: two feature ideas, one question, one minor bug. It's the pivotal moment every creator knows: the app works — but an app that works is not yet a product. A product is an app plus a loop: you measure, you listen, you decide, you iterate. This chapter installs that loop, then sends you off toward your next project.

Measuring: numbers without spying

A product manager's first question: "who actually uses what?". Impressions lie — numbers, less so. But beware the "Google Analytics" reflex: for a small app, especially one used by minors, you want a privacy-friendly analytics tool like Plausible or Umami: no cookies, no profiling, no endless consent banner, just anonymous counters. The integration fits in one line the AI will add in thirty seconds, and the dashboard tells you the essentials: how many visits, which pages, which days.

The next trap is watching the wrong numbers. Visit counts flatter the ego but say nothing useful: that's called a vanity metric. Tom picks himself a north-star metric — THE number that says whether the app fulfills its mission: "how many students check off at least one habit three days a week?". Everything else (visits, accounts created, page views) is just scenery around that question. Choose yours with the same criterion: if that number goes up, your app is objectively more useful.

Listening: organizing the feedback

Tom's scattered messages — a text, two emails, a word at recess — are the symptom of a product without a feedback channel. The solution is inside the app itself: a small "an idea? a problem?" button, a mini-form, and every submission filed in a database table. You have every skill needed to build it — it's even an excellent synthesis exercise of chapters 6 through 9: a form (validated inputs!), a Supabase table (with RLS!), a submission limit (chapter 9!):

Add a feedback module to my habit-tracking app.
What I want:
1. a small discreet "an idea? a problem?" button at the bottom of the main page
2. on click: a mini-form with a 500-character max text field and a "bug / idea / other" choice
3. each submission is saved in a feedback table in Supabase with the user_id, the category and the date — with Row Level Security enabled
4. limits: 5 submissions per user per day, server-side content validation, a thank-you message after sending
5. also create an /admin page accessible only to my account, listing the feedback from newest to oldest with a counter per category
One step at a time, I test before continuing.

Once the module is in place, the interpretation rule: requests are not needs. When three students ask for "a dark mode", the real need might be "the app blinds me at night in the dorm". Before adding what you're asked for, trace back to the problem: "what bothers you, concretely, and when?". Sometimes the right answer is the requested feature; often, it's a simpler solution nobody had put into words.

Prioritizing: the solo-builder’s matrix

With analytics on one side and feedback on the other, your "later" list will swell fast. The sorting happens with four questions, in this order: how many users are affected? (an irritant mentioned five times beats a brilliant idea mentioned once), is it aligned with your north-star metric? (a feature that doesn't serve the mission can wait), what effort? (ask the AI to estimate: small, medium, big project), and is it reversible? (an experiment you can remove is attempted more freely than a permanent commitment).

• Many users + aligned + small effort: do it this week.
• Aligned but big effort: break it into a mini-PRD (chapter 3) and spread it out.
• Few users affected: let it mature — if it comes back three times, it will climb on its own.
• Not aligned with the mission: decline politely, even if it’s a good idea. Especially if it’s a good idea.

The last point is the hardest and the most important: saying no. Every added feature is a surface to maintain, debug and secure forever. The best products aren't the ones that do the most things, they're the ones where everything serves the mission. Tom thus declines a "chat between students" — excellent idea, wrong product: his mission is habits, not messaging.

Monetizing without betraying yourself

Chapter 8's Payment Link turned Tom's app into an activity that earns — modestly, but really. The time has come to think it through calmly. The models suited to a small app: freemium (the core free, paid comforts — Tom's choice: free for students, a "classroom" version with a dashboard for teachers), one-time payment (simple and honest, suited to tools), donations (viable for a tool loved by a community), and subscription (reserved for obvious recurring value — don't inflict it on a tool used twice a month).

Two principles when setting the price. First, consistency with the mission: Tom will never charge a student — the mission is educational, so schools and teachers do the funding. Second, simplicity: one single paid plan, a round price, a page that explains it in three benefits. You can add complexity when you have a hundred customers; at five customers, every hour spent on the pricing grid is an hour stolen from the product.

Getting known: show the problem, not the tech

Word of mouth brought Tom three classes; to go further, he needs a real landing page — the one a teacher discovers by clicking the link shared in the staff room. The beginner's golden rule: you don't sell the technology, you show the problem solved. Nobody signs up for "a Supabase app with RLS"; people sign up to "help your students stick to their work routines". Tom has it generated with all his prompting know-how:

Create a marketing landing page for my habit-tracking app, on the /home route.
Audience: middle-school teachers discovering the app through a colleague — not developers.
Structure:
1. a headline about the problem solved: helping students stick to their work routines
2. three concrete benefits in three cards, without any technical jargon
3. a screenshot of the app in the center, clean, on a light background
4. a short teacher testimonial — I will provide the exact text
5. two buttons: "try it for free" to the sign-up, and "classroom plan" to the payment page
Style: consistent with the app, clean, green accent, reassuring, readable on a phone.
The page must load fast: no heavy animations, no unnecessary libraries.

The sustainable rhythm: iterating without burning out

Last ingredient of the product: the rhythm. The classic post-launch mistake is the permanent sprint — three features a week for a month, then complete abandonment. The solo-builder's sustainable rhythm looks more like this: one improvement per week, chosen through the prioritization matrix, delivered with the chapters 3-4 method (mini-PRD if it's big, build-test-commit always), plus a weekly quarter-hour of hygiene: a glance at the analytics, feedback triage, a look at the status pages and the AI spending cap.

And accept a counter-intuitive idea: a product can be finished. If the north-star metric is good, the feedback dries up and the app delivers exactly the service intended, you have the right to let it run in maintenance mode and move on to something else. "Finished and useful" is a glorious state, not a failure of ambition. Not every app is meant to become an empire — Tom's does precisely what it should, and that's its greatest quality.

Your journey — and the next project

Take a second to measure the distance traveled, because it's considerable. In ten chapters, you've learned to frame an idea (mini-PRD), choose tools, build iteratively, debug methodically, deploy, authenticate users, centralize data securely, connect external services, secure the whole thing, and steer a product with numbers and feedback. These aren't "beginner vibe coder" skills: this is, quite exactly, the complete life cycle of a software product — the one professional teams follow, which you now know how to run by conversing with an AI.

What comes next writes itself: pick a second project, one notch more ambitious, and run the whole cycle again. You'll go three times faster — not because the AI will have improved, but because you will know what to ask, what to demand, what to test and when to say no. That was this course's secret goal from the very first page: not to teach you how to build an app, but to teach you how to build as many as you want. Tom already has his next idea — a reading journal for the school library club. What about you?