Run your app, watch it, and know when to call a real developer.
~15 min · Your shipped capstone open · Prereq: B17 (Build Sprint)
Shipping is not the end — it's the beginning of a new and simpler job: keeping the
lights on and knowing when to ask for help. Most entrepreneurs who build with AI get
this backwards. They over-engineer the monitoring and under-invest in the judgment to
know when to hand off. Your single win from this final lesson: a clear mental model for
watching costs, handling breakages, recognising your limits, and continuing to build
from here — confidently, and without pretending you need to do it all alone.
Watching your costs
A live app costs money in ways that can quietly compound if you don't watch them.
None of these will bankrupt you overnight — but they are worth reviewing once a month
rather than once a shock bill arrives:
AI creditsClaude, GPT, or whichever model powers your features. Set a spending limit in the provider dashboard. Know your per-call cost so a traffic spike doesn't land as a surprise invoice.
HostingVercel, Railway, Render, Supabase free tiers are generous — but check what triggers a paid tier (traffic, storage, build minutes). Set a billing alert.
EmailResend, Postmark, and similar services charge per message over a free tier. A bug that sends duplicate emails can spike your bill fast — monitor your send counts.
Stripe feesStripe charges a percentage of each transaction. Not a "cost" you control, but know your margin before you price. Also watch for failed-payment retry fees.
The two-minute monthly check: once a month, log in to your AI provider,
your hosting dashboard, your email provider, and Stripe. Look at the cost chart. If any
line is trending up faster than your revenue, investigate before the next bill.
That's the whole monitoring practice for a small app.
What to do when something breaks
Things will break. That is not a failure — it is the normal operating condition of any
live software. What matters is how fast you recover. Follow this order every time:
Revert first, diagnose second.
If something broke after a recent change, roll back to the last working version
(your git history makes this a single command). Get the app working again, then
investigate the cause. Never debug on a broken live app if you can avoid it.
Check the logs.
Your hosting platform shows server logs in real time. Your browser's developer tools
show client-side errors. The error message is almost always there — you just have to
look. Copy the exact error text before you do anything else.
Ask the AI with the exact error.
Paste the error message, the file it points to, and a short description of what you
changed. The AI will identify the likely cause and suggest a fix. Vague descriptions
get vague answers — the more precise you are, the faster you move.
If you're stuck after 30 minutes, call a developer.
Not as a defeat — as a skill. Knowing when to escalate is one of the most valuable
judgments a founder can make.
The genuinely empowering skill of knowing your limits
A non-technical founder who knows their limits is more valuable — to their business,
to their team, to their customers — than one who pretends they don't have any. Knowing
your limits doesn't mean being passive. It means you know when the right next move is
to hire a freelance developer for a day, post in a community, or hand a scoped problem
to someone with deeper expertise.
You now know enough to write a precise brief for that developer. You can describe the
problem in technical terms, point at the relevant files, and tell them exactly what
"fixed" looks like. That brief cuts their time in half and yours in cost.
That is the skill. You don't need to fix every bug yourself —
you need to be able to hand it off well.
What to build next — and where to keep learning
You've shipped one real app. Here is how to continue building from here:
A roadmap for what comes next:
Add one thing to your capstone v2. The list of ideas you parked during the sprint — revisit it. Pick one, scope it the same way you scoped the capstone, ship it. Iteration is the whole practice.
Automate one more workflow. Go back to the automations from Course A. Now that you can build apps, you can also build the tools those automations talk to.
Build a skill for one process you run every week. You learned how in B15. Packaged expertise compounds — your future self will thank you.
Find your community. The people building with AI as non-technical founders are the most generous community in tech right now. See RESOURCES.md for forums, newsletters, and communities worth joining.
Teach someone else. Nothing cements understanding like explaining it. Find one entrepreneur who is where you were at the start of Course A and walk them through the first three lessons. You'll discover exactly how much you now know.
Check yourself
Answer before opening. Recalling it now is what makes it stick.
Your email provider bill is three times higher than last month and you didn't add any new features. What's the first thing you check?
Check your email send logs for duplicate sends or a loop. A bug that triggers the same email multiple times per event is the most common cause of an unexpected email spike. Look at the logs first — you'll almost certainly see the pattern immediately.
You've been debugging a broken authentication flow for 45 minutes, the AI's suggestions aren't landing, and users are locked out. What do you do?
Revert to the last working version to restore access, then hire a developer for a scoped fix. User-facing breakage that you can't resolve in 30 minutes is the moment to escalate. Revert first (get users back in), then hand a precise brief to a developer. Spending another two hours guessing is the wrong call.
A developer friend says "you'll always need a developer to run a real app." How do you respond?
Not for the day-to-day — but yes, sometimes, and that's fine. You can handle monitoring, cost watching, minor fixes, and iteration yourself. You now know enough to write a precise brief when you do need expert help. That's not dependency — that's judgment. The goal was never to replace developers; it was to stop being afraid of building.
Read this next (primary source)
"Building Your First AI Feature" (mean.ceo) —
a thoughtful guide to the founder mindset around shipping and maintaining AI-powered
features, including when to own it and when to hand off. A good place to land after
finishing this course. See RESOURCES.md for more.
I'm your teacher — and I want to hear what you built. Tell me what your
capstone does, what the hardest part was, and what you want to build next. This whole
course was designed around the premise that non-technical founders can build real
software — and you just proved it. That conversation is worth having.
You came into this program without a technical background and you are leaving it having
automated workflows, built and shipped a real app with auth or data or payments, and — most
importantly — with the judgment to know what to build next and when to ask for help.
That is genuinely rare, and it compounds. Everything you build from here gets faster.
Congratulations — go ship something.
Every term from both courses lives in the
course glossary — keep it as a reference
long after the course is done.