AI for Entrepreneurs — Part 2

Why: You left Part 1 with a deployed project and a 30-day plan. What happened? What did you build? What broke? What questions came up when you were on your own? What: Quick round-the-room: each person shares their Part 1 project status — what they built since, what they got stuck on, what they want to build this week. Sets the tone: this is a room of builders now, not beginners. How: Each person shares in 2 minutes. Facilitator captures common themes and questions on a whiteboard. What If: What if the room you walked into already felt like a team — because everyone's been building since Part 1?

Why: Your Part 1 project was static — hardcoded content, no memory, no users. Every real application needs to store and retrieve data. That's what a database does. What: What a database is (structured storage with rules). Tables, rows, columns — it's a spreadsheet that software can talk to. SQL = the language for asking a database questions. Supabase = a database you can set up in 60 seconds with a UI. CRUD: Create, Read, Update, Delete — the four things every app does with data. How: Demo — add a Supabase database to the class portal live. Create a table, insert data, query it, display it on the page. Then each person adds a database to their own project. What If: What if your app could remember everything — every user, every interaction, every piece of data — and you could set that up in an afternoon?

Why: Right now anyone with your URL sees the same thing. Authentication means users can sign up, log in, and have their own experience. That's when your project becomes an app. What: What auth is: identity (who are you?) and authorization (what can you access?). Signup, login, sessions, tokens — how it works under the hood. Supabase Auth — add login to any project in minutes. Social login (Google, GitHub). Protected routes — pages only logged-in users can see. How: Demo — add auth to the class portal. Signup page, login page, protected content. Each person adds auth to their project. What If: What if your project had real users tomorrow — signing up, logging in, using something you built? NESTED LOOPS: Overt = learn auth. Loop 2 = they're thinking about their product from the user's perspective for the first time — product thinking deepens.

Why: Your app doesn't have to do everything itself. APIs let you connect to any service on the internet — weather data, payment processing, AI models, social media, anything. What: APIs demystified — it's just one piece of software asking another piece of software for something. Request/response model. JSON = the format they speak. API keys = your password. REST vs. GraphQL (just know REST for now). Free APIs to play with. How: Demo — connect to a real API live (weather, stock price, or AI). Show the data flowing into the app. Each person picks an API relevant to their project and connects it. What If: What if your app could pull data from anywhere on the internet — and you could set that up in 20 minutes?

Why: A great app that looks ugly doesn't get used. You don't need to be a designer — you need to know 5 rules that make anything look professional. What: The 5 rules: (1) Consistent spacing — use a system, not your eyes. (2) Typography hierarchy — one font, three sizes. (3) Color constraint — pick 2-3 colors, no more. (4) Alignment — everything lines up with something. (5) Responsive design — it works on phones too. Component libraries: Tailwind, shadcn/ui — pre-built beautiful components. How: Before/after makeover — take the class portal from 'functional' to 'professional' by applying the 5 rules live. Each person applies at least 2 rules to their project. What If: What if everything you built looked like it was designed by a professional — because you followed 5 simple rules?

Why: You learned databases, auth, APIs, and design today. Now integrate them into your actual project. What: Hands-on build time — add a database and auth to your Part 1 project, or start a new one from the problem you brought. Facilitator floating for 1-on-1 help. How: 60 minutes of focused building. Check-in at 30 minutes. What If: What if your static Part 1 project just became a real application — with users, data, and a professional look?

Why: You've been building by trying things and seeing if they work. That works until it doesn't — until a change in one place breaks something in another place and you don't notice until a user tells you. Tests are your safety net. What: TDD = write the test first, then write the code that makes it pass. Red (test fails) > Green (test passes) > Refactor (make it clean). Why writing the test first changes how you think — you define success before you build. Unit tests (does this one piece work?), integration tests (do the pieces work together?). How: Demo — write tests for the class portal live using TDD. Red > green > refactor cycle. Each person writes 3 tests for their project. What If: What if you could change anything in your code and know in seconds whether you broke something? NESTED LOOPS: Overt = learn TDD. Loop 2 = 'define success before you build' is a life principle, not just a coding one. Loop 3 = the discipline of writing tests first trains structured thinking that transfers to business planning, goal setting, everything.

Why: Writing some tests is good. Knowing how much of your code is tested — and what's not — is better. What: Coverage reports — what percentage of your code runs during tests. What 80% coverage means (and why 100% isn't the goal). What to test: business logic, user flows, edge cases. What not to test: UI styling, third-party libraries. How to read a coverage report and know where your blind spots are. How: Run a coverage report on the class portal. Identify untested code. Write tests to close the gaps. Each person runs coverage on their project and identifies the top 3 gaps. What If: What if you had a dashboard that told you exactly how confident you should be in your code — and exactly where the risk is?

Why: Your project lives in a browser. Your users live on their phones. Bridging that gap used to require learning a whole new programming language. Now it doesn't. What: Expo and React Native — write once, run on iOS and Android. The web-to-mobile bridge: your web project can become a mobile app with the same codebase. What changes (navigation, touch, screen size) and what doesn't (logic, data, API connections). App Store vs. TestFlight vs. web apps. How: Demo — wrap the class portal in an Expo mobile shell. Show it running on a phone simulator. Each person starts a mobile version of their project. What If: What if the app you built this week was on your phone by tonight — and on the App Store next month?

Why: Right now you deploy manually — push code, hope it works. CI/CD means every time you push code, tests run automatically. If they pass, it deploys automatically. If they fail, you know before your users do. What: CI = Continuous Integration (run tests on every push). CD = Continuous Deployment (deploy automatically when tests pass). GitHub Actions — free, built into GitHub. The pipeline: push > tests run > if green, deploy > if red, stop and fix. How: Demo — set up a GitHub Action for the class portal. Push a change, watch tests run, watch it deploy. Then push a broken change, watch the tests catch it. Each person sets up CI/CD for their project. What If: What if your code tested itself and deployed itself — and you only got a notification when something was wrong?

Why: Your app is deployed. Users are coming. But you're blind — you don't know who's using it, what they're doing, or when things break. Monitoring and analytics give you eyes. What: Error tracking (Sentry — know when something breaks before users report it). Usage analytics (PostHog, Vercel Analytics — know what features people use, where they drop off). Uptime monitoring (is your site up?). The dashboard mindset: exceptions only, not status reports. How: Demo — add error tracking and analytics to the class portal. Trigger an error, see it in the dashboard. Each person adds monitoring to their project. What If: What if you knew exactly how people used your app — and got an alert the moment something broke?

Why: You've built something people can use. The question every entrepreneur arrives at: can people pay for it? Stripe makes this shockingly simple. What: Stripe — the payment infrastructure of the internet. Checkout sessions, subscriptions, one-time payments. Test mode (fake money, real flow). Pricing models: one-time, subscription, usage-based, freemium. The psychology of pricing. How: Demo — add a Stripe checkout to the class portal (test mode). Click, pay, see the payment appear. Each person designs a pricing model for their project and wires up a test payment. What If: What if the project you built this week could accept its first dollar next week?

Why: In Part 1 you used Claude Code for single changes. Real development means multi-file refactors, codebase-wide improvements, and complex feature builds. What: Advanced patterns: working across multiple files simultaneously, refactoring without breaking things, using tests as a safety net for big changes (TDD + Claude Code = fearless refactoring). Project-level context files (CLAUDE.md). Chaining complex tasks. How: Demo — take the class portal and do a major refactor with Claude Code, using tests to verify nothing broke. Each person does a significant improvement to their project using advanced workflows. What If: What if you could confidently make massive changes to your codebase — because you had tests as a safety net and an AI collaborator that understands the whole project?

Why: In Part 1 we showed you what a VPS is. Now you set one up. A server that's always on, always available, running your projects and your automations 24/7 — accessible from your phone, your laptop, anywhere. What: Choosing a VPS provider (DigitalOcean, Hetzner — $5-20/mo). SSH = remote access to your server. Setting up a server from scratch: install Node, clone your project, run it. The mental model: your laptop is your workshop, your VPS is your factory. How: Hands-on — each person provisions a VPS, SSHs in, clones their project from GitHub, and gets it running live. Deploy from the server. See it persist after closing the laptop. What If: What if your projects ran 24/7 without your laptop being open — and you could check on them from your phone at breakfast?

Why: You've built things that run when a user visits. But what about tasks that should run automatically — every morning, every hour, every week? That's a cron job. What: Cron = scheduled tasks that run automatically on your server. The cron syntax (it's just 5 numbers: minute, hour, day, month, weekday). Real examples: scrape a website daily, send a report every Monday, sync data every hour, check if your site is up every 5 minutes. How: Demo — set up a cron job on the VPS that runs a script automatically. Show the logs. See it fire on schedule. Each person designs a cron job relevant to their business and sets it up. What If: What if you had a tireless assistant that ran tasks for you at exactly the right time, every time, forever — and it cost $5/month?

Why: Everything so far has been you directing AI — you ask, it answers, you decide. Agents flip that. An agent takes a goal, breaks it into steps, executes them, and reports back. You give it the destination, it drives. What: What an AI agent is: a loop of think > act > observe > think again. The difference between a chatbot (you drive) and an agent (it drives). Real examples: an agent that monitors your competitors' websites and emails you changes, an agent that processes incoming emails and drafts responses, an agent that writes and publishes social media content on a schedule. Claude Code itself is an agent — it reads your project, decides what to do, executes, and checks its work. How: Demo — build a simple agent live: give it a task, watch it break it down, execute steps, and deliver a result. Then: design an agent for your business on paper — what would it monitor, decide, and do? What If: What if you had AI employees that worked 24/7, never called in sick, and cost less than your phone bill?

Why: VPS + cron jobs + agents + CI/CD + monitoring = an autonomous system. Your projects run themselves. Your agents work while you sleep. Your tests catch problems before users do. Your dashboards tell you when something needs your attention. This is the endgame. What: The full stack: code on GitHub > CI/CD tests and deploys > VPS runs it 24/7 > cron jobs handle scheduled tasks > agents handle complex decisions > monitoring alerts you to exceptions. The entrepreneur's infrastructure — lean, automated, independent. How: Demo — walk through the complete stack running live. Show a change flowing from code to deploy to running on the server with agents and crons active. Each person maps their ideal autonomous stack on paper. What If: What if your business had an infrastructure that ran, monitored, and improved itself — and you only got involved when a decision required your judgment?