Pro Vibe Coding

From prototype to real product. Build apps people pay for, use daily, and trust with their data.

A guide for people who finished Pre-Vibe Coding and are ready to build real things.

This guide shows you how — still using AI as your builder, still in simple language, still no coding degree required.

Chapter 1: From Toy App to Real Product

You built a to-do app. Or a landing page. Or maybe a little dashboard that shows some data. Congratulations — seriously. Most people never get that far.

But you've noticed something. Your app feels like a toy. Nobody can log in. There's no way to pay. If the data disappears, nobody would care because nobody is using it.

That's fine. You were running a food truck.

The food truck to restaurant analogy.

Your to-do app? That was a food truck. You parked it on the street, made some tacos, and people said "hey, these are good." The cooking was real. The food was real. But there was no front door, no cash register, no health inspection, and no manager watching the floor.

Now you're opening a restaurant. The cooking is the same — the AI still writes the code. But a real restaurant needs:

• A front door with a lock (authentication — letting the right people in)
• A cash register (payments — getting money from customers)
• A health inspection certificate (security — keeping data safe)
• A manager watching the floor (monitoring — knowing when things break)
• A reservation system (user accounts and data)
• A menu that makes sense (real UI, not just a prototype)
• A kitchen that doesn't catch fire (error handling)
• A supply chain (file storage, email, third-party services)

Those are the 8 features almost every real app needs. And here's the good news: you don't need to build them all at once.

Build in layers.

Start with the MVP — Minimum Viable Product. That's a fancy way of saying: what's the least you can build and still have something useful?

• Layer 1: Authentication + core feature. People can log in and do the main thing.
• Layer 2: Payments. People can pay you.
• Layer 3: Polish. Emails, file uploads, search, admin tools.
• Layer 4: Production hardening. Security, error handling, monitoring.

Each layer makes your app more real. And each layer is a conversation with the AI.

That prompt alone shifts the AI from "toy mode" to "real app mode." You're telling it: I'm serious now. Build it like it matters.

Chapter 2: Choosing Your Stack (Without Overthinking It)

A "stack" is just the set of tools your app is built with. That's it. It's not complicated.

The kitchen analogy.

Choosing a stack is like choosing what kind of kitchen to set up. Gas stove or electric? Commercial oven or home oven? Wok or cast iron? Each choice works fine. Professional chefs have preferences, but the food comes out good either way.

People will tell you to use Rust or Go or Elixir or whatever the hot thing is this month. Ignore them. For vibe coding, you need a stack where the AI is deeply knowledgeable and can write reliable code fast.

That narrows it down to two great options.

Option 1: The Python Stack

Frontend:  React or plain HTML/CSS/JavaScript
Backend:   FastAPI (Python)
Database:  PostgreSQL
ORM:       SQLAlchemy or Prisma

FastAPI is a Python backend framework. It's fast, modern, and AI knows it inside and out. If you're more comfortable with Python-style thinking (or you plan to do anything with data, AI, or machine learning later), go here.

Option 2: The JavaScript Stack

Frontend:  Next.js (React-based)
Backend:   Next.js API routes (built in) or Express
Database:  PostgreSQL
ORM:       Prisma

Next.js does frontend AND backend in one framework. One language (JavaScript/TypeScript) for everything. If you want the simplest setup with the fewest moving parts, go here.

Both stacks use PostgreSQL. That's the database. It's the industry standard. It's free. It handles everything from 10 users to 10 million. SQLite was fine for your toy app. PostgreSQL is for your real app.

Here's the important part: pick one and move on.

Do not spend three days reading comparison articles. Do not ask on Reddit. The AI is excellent with both stacks. The one you pick will work. The best stack is the one you actually start building with.

The AI will generate a project structure that looks professional. Folders organized. Config files set up. Database connected. You just jumped ahead by about two days compared to doing it manually.

One more thing: you'll see the term ORM come up. An ORM is a translator between your code and your database. Instead of writing raw database commands, you write normal code, and the ORM translates it. Think of it like having a bilingual assistant — you speak English, the database speaks SQL, and the ORM handles the conversation.

Chapter 3: How Login Actually Works

Every app you use has a login screen. Gmail, Netflix, Instagram — they all ask you to prove who you are before they let you in. Let's understand what actually happens behind that screen.

The wristband at a concert.

You go to a music festival. At the gate, you show your ticket. They check it. If it's valid, they put a wristband on you. For the rest of the day, you don't show your ticket again. You just flash your wristband. Security sees it and lets you through.

That's exactly how login works on the internet. Here's the step-by-step:

That's the whole thing. Every login system in the world works this way. The details vary, but the pattern is always the same.

Sessions vs. tokens — two kinds of wristbands.

There are two ways to handle that "wristband":

Sessions — the venue keeps a list. When you log in, the server writes your name on a list and gives you a number. Every time you make a request, you show your number. The server checks the list: "Number 4729... yep, that's Sarah, she's allowed in." The proof lives on the server.

Tokens — you carry the proof. When you log in, the server gives you a special wristband with your info encoded into it. Every time you make a request, you show the wristband. The server reads the wristband itself — it doesn't need to check a list. The proof lives with you. The most common type is called a JWT (JSON Web Token — pronounced "jot").

Most modern apps use tokens. They're simpler to scale because the server doesn't need to maintain a list.

Why passwords are NEVER stored as-is.

This is important. No responsible app stores your actual password. Ever.

Imagine you write a secret message on a piece of paper, then feed it through a shredder that creates a unique pattern. You can't un-shred it — you can't turn the shredded paper back into the message. But if someone writes the same message and shreds it with the same shredder, they'll get the exact same pattern.

That's hashing. When you create an account, the server takes your password, runs it through a mathematical "shredder" (a hash function), and stores the shredded version. When you log in later, the server shreds what you typed and checks: does this shredded version match the stored one?

If a hacker steals the database, they get shredded passwords. Useless. They can't un-shred them.

Three ways people log in:

1. Email + password — the classic. You pick a password, the app stores a hash of it.
2. OAuth / "Sign in with Google" — you let Google (or Apple, GitHub, etc.) vouch for you. The app never sees your password at all. Google says "yep, this person is legit" and the app trusts Google.
3. Magic links — the app sends a special one-time link to your email. You click it, you're in. No password to remember. Slack uses this.

Each approach has tradeoffs. OAuth is easiest for users (one click). Email + password is most familiar. Magic links are the most secure but require a working email system.

Chapter 4: Building Auth With AI

Here's the golden rule of authentication: do not build it from scratch.

Authentication has a thousand ways to go wrong. Password storage, session management, token expiration, CSRF attacks, brute force protection — the list goes on. Smart developers don't write this themselves. They use battle-tested tools.

You have two paths:

Path 1: Libraries (you host everything)

A library is code that plugs into your app. Your app handles the login, but the library does the hard security work.

• NextAuth.js (now called Auth.js) — for Next.js apps. Handles OAuth, email login, sessions. Very popular. Free.
• Flask-Login / FastAPI Users — for Python apps. Handles sessions and user management.

Pro: Free. Full control. Your data stays with you.
Con: More setup. You manage the database, password hashing, and email verification yourself (though the library helps).

Path 2: Services (someone else handles it)

A service is an external company that handles all of authentication for you. You just connect to them.

• Clerk — beautiful prebuilt login pages. Drop-in components. Great for getting started fast.
• Auth0 — industry standard. Used by big companies. Generous free tier.
• Supabase Auth — comes free with Supabase (a database + auth combo). Great if you already use Supabase.

Pro: Way less work. Battle-tested security. Prebuilt UI for login, signup, password reset.
Con: You depend on an external service. Costs can grow with users.

When to use which?

• Starting a brand-new project and want speed? Use a service like Clerk or Supabase Auth.
• Adding auth to an existing project? Use a library like NextAuth.js.
• Building something you want full control over? Use a library.

The signup flow:

The login flow:

Password reset:

"Remember me":

Adding "Sign in with Google":

For OAuth, you'll need to set up a Google Cloud project and get API keys. The AI will walk you through it, but just know: this part involves some clicking around in Google's dashboard. It takes about 10 minutes.

Chapter 5: Protecting Pages and Data

You have login working. Users can sign up and log in. But right now, anyone can still visit any page by typing the URL directly. That's like having a front door with a lock — but leaving all the windows open.

The bouncer pattern.

Think of every page in your app as a room in a nightclub. Some rooms are open to everyone — the landing page, the pricing page, the login page. Those are the lobby.

But the dashboard? The settings page? The admin panel? Those rooms have a bouncer. Before you walk in, the bouncer checks: "Do you have a wristband? Is it valid? OK, come in." If you don't have one, the bouncer sends you to the front door (the login page).

That's called a protected route. A route is just a URL path (like /dashboard or /settings). A protected route is one that requires login.

Authentication vs. authorization — two different questions.

These two words sound similar but mean very different things.

Authentication = Who are you? (Checking the wristband.)
Authorization = What are you allowed to do? (Checking if your wristband gives you backstage access.)

A logged-in user can see their own dashboard. But can they see OTHER people's dashboards? Can they delete posts? Can they access the admin panel?

That's authorization. And it comes down to roles.

Roles: who can do what.

Most apps have at least two roles:

• User — can use the app, see their own data, manage their own account
• Admin — can see everything, manage all users, change settings

Some apps have more:

• Moderator — can review and remove content, but can't change app settings
• Editor — can create and edit content, but can't manage users
• Viewer — can see things but can't change anything

In the database, this is usually just a column on the user table. Something like role: "admin" or role: "user". Simple.

Row-level security: users only see THEIR data.

This one is critical. Imagine your app has a notes feature. Every user has their own notes. If you're not careful, User A could see User B's notes just by changing a number in the URL.

Row-level security means: when the database looks up notes, it automatically filters to only show notes belonging to the logged-in user. It's like having a filing cabinet where each drawer only opens for its owner.

Chapter 6: How Online Payments Work

Here's the most important rule of online payments: you never touch the credit card.

Seriously. You never see card numbers. You never store card numbers. You never process card numbers. If you do, you're breaking laws and begging for a lawsuit.

So how does it work?

The cash register analogy.

Imagine you open a store. You could build your own cash register from scratch — figure out how to accept credit cards, handle receipts, deal with refunds, talk to the bank, handle fraud. Or you could just buy a cash register that does all of that already.

That cash register is Stripe.

Stripe is a company that handles payments. You send a customer to Stripe, Stripe collects their money, and Stripe sends you the money (minus a small fee, usually about 3%). You never touch the card. Stripe handles the security, the fraud detection, the receipts, the tax — all of it.

There are other payment processors (PayPal, Square, Braintree), but Stripe is the standard. Almost every startup uses it. The AI knows Stripe inside and out. Use Stripe.

What happens when someone pays — step by step:

Notice: your app never sees the credit card. At step 3, the user leaves your app (or sees a Stripe overlay), enters their card info on Stripe's secure page, and then comes back. Your app only hears "it worked" or "it didn't."

One-time payments vs. subscriptions.

One-time payment — the customer pays once, gets the thing. Like buying a book. You charge $20, they get access.

Subscription — the customer pays every month (or year). Like Netflix. You charge $10/month, they get access as long as they keep paying. If they cancel, access stops.

Most SaaS apps (Software as a Service — apps you pay monthly for) use subscriptions. Stripe handles both.

Chapter 7: Building Payment Features

Let's get practical. Here's how to actually add payments to your app.

Step 1: Set up Stripe.

You need a Stripe account. Go to stripe.com and sign up. It's free — Stripe only takes a fee when you actually process payments. You'll get two important keys:

• Publishable key — safe to use in your frontend (starts with pk_)
• Secret key — NEVER expose this in the frontend (starts with sk_)

Put both in your .env file. The AI will know what to do with them.

Step 2: Use Stripe Checkout (the easiest way).

Stripe Checkout is a prebuilt payment page hosted by Stripe. You don't design it. You don't build it. You just redirect your user to it. Stripe handles the card form, validation, security, receipts — everything.

Step 3: Understand webhooks.

This is the part that confuses people, but it's actually simple.

A webhook is when Stripe calls YOUR app to tell you something happened. Think of it like a restaurant calling to confirm a reservation. You called and made the reservation (started the payment). Later, the restaurant calls YOU back: "Just confirming your table for 7 PM" (payment succeeded).

Why can't you just check if the payment worked when the user comes back to your success page? Because users can close the browser. They can lose internet. They can refresh. The redirect isn't reliable. The webhook IS reliable — Stripe will keep trying until your app confirms it received the message.

Step 4: Testing.

Stripe has a test mode. Every Stripe account comes with test API keys (they start with pk_test_ and sk_test_). In test mode, you can use fake credit cards:

• 4242 4242 4242 4242 — always succeeds
• 4000 0000 0000 0002 — always declines

Use test mode until everything works perfectly. Then switch to live keys when you launch. The code doesn't change — just the keys.

Chapter 8: Subscriptions and Billing

Most real apps don't just charge once. They have plans. They have tiers. They have billing pages where users manage their subscription. Let's build all of that.

Plans and tiers.

Almost every SaaS app has three tiers. Here's a common pattern:

In your database, each user has a plan field. It's something like "free", "pro", or "enterprise". When a user tries to use a Pro feature, your app checks: is their plan "pro" or higher? If not, show them the upgrade page.

Tracking which plan a user is on.

This lives in your database. You need a few fields on each user:

• plan — which tier they're on (free, pro, enterprise)
• stripe_customer_id — links this user to their Stripe account
• stripe_subscription_id — which Stripe subscription is active
• subscription_status — active, cancelled, past_due, trialing

When Stripe sends a webhook saying "this subscription was renewed," you update these fields. When Stripe says "this subscription was cancelled," you update them again.

Upgrading and downgrading.

When a user upgrades from Free to Pro, you create a new Stripe subscription. When a user upgrades from Pro to Enterprise, you update the existing subscription to the new price. When they downgrade, same thing — update the subscription, and Stripe handles the prorating (charging the right amount for the partial month).

Cancellation.

When a user cancels, you have a choice: cancel immediately, or cancel at the end of the billing period. Most apps cancel at the end of the period — the user already paid for this month, so let them finish it.

Invoices.

Stripe generates invoices automatically. You can show them in your app by pulling them from the Stripe API. Users like having a billing history page where they can download past invoices.

That's a big prompt. The AI might take a few rounds to get everything right. That's normal. Break it into pieces if needed — pricing page first, then billing page, then webhooks.

Chapter 9: Beyond Simple Tables

Your toy app probably had one or two database tables. A tasks table for your to-do app. A posts table for your blog.

Real apps have 5, 10, 15, sometimes hundreds of tables. And those tables connect to each other in important ways.

Relationships: how tables connect.

Think of your database like a family tree. People are related to each other — parents have children, siblings share parents, cousins connect through grandparents. Database tables work the same way.

One-to-many: one parent, many children.

One user has many posts. One store has many products. One class has many students.

In the database, this means the "child" table (posts) has a column that points back to the "parent" table (users). Each post has a user_id that says "I belong to this user."

Many-to-many: friends that go both ways.

Students and classes. A student takes many classes. A class has many students. Neither "belongs to" the other — the relationship goes both ways.

You can't just add a student_id column to the classes table (because each class has MANY students). And you can't add a class_id column to the students table (because each student has MANY classes).

The solution: a third table that sits in between. It's called a join table (or junction table). It just has two columns: student_id and class_id.

One-to-one: a single pair.

One user has one profile. One order has one receipt. This is less common but shows up when you want to split a big table into smaller ones.

Database migrations: renovating your house one room at a time.

As your app grows, you'll need to change your database. Add a column here, rename a table there, create a new relationship.

A migration is a file that describes one change to your database. Think of it like renovating your house. Each migration is one renovation job: "add a bathroom to the second floor" or "knock down the wall between the kitchen and dining room."

You keep all your migrations in order. Migration 1, then 2, then 3. Each one builds on the last. If you need to set up the database on a new computer, you just run all the migrations in order and you get the exact same structure.

This is version control for your database. And it's essential for real apps — because you'll change your database design many, many times.

Indexes: bookmarks for fast searches.

When you search a book, you use the index in the back. You don't read every page — you look up the topic in the index and jump to the right page.

Database indexes work the same way. If you often search for users by email, you add an index on the email column. Now the database can find users by email instantly instead of scanning every single row.

Rule of thumb: add indexes on any column you search, sort, or filter by frequently.

When SQLite isn't enough.

SQLite is a simple database that stores everything in a single file. It's great for learning and prototyping. But it struggles with multiple users accessing it at the same time, and it can't handle complex queries well.

PostgreSQL is the real deal. It handles thousands of simultaneous users, supports advanced features, and is what production apps use. Switching from SQLite to PostgreSQL is like going from a notebook to a filing system — same concept, much more capable.

Chapter 10: Users, Roles, and Permissions

Every real app has different types of users who can do different things. Your job is to decide who can do what.

Simple approach: a role column.

The easiest way to handle roles is a single column on the users table called role. It holds a value like "user", "admin", or "moderator".

Then in your code, you check: if the user's role is "admin", let them do admin stuff. If not, show a "not authorized" message.

This works for most apps. If you have 2–4 roles with clear boundaries, this is all you need.

Flexible approach: a permissions table.

What if you want fine-grained control? Maybe some moderators can delete posts but not ban users. Maybe some admins can manage billing but not view user data.

Then you use a permissions table. Instead of one "role" column, you have a whole table that maps users to specific abilities:

Alice (user 1) can manage users, billing, and delete posts. Carol (user 3) can delete posts and ban users. Bob has no special permissions — he's a regular user.

This is more work to set up. But it gives you total flexibility. Use it when your roles aren't clean-cut.

Multi-tenancy: apartments in a building.

Some apps serve multiple companies or organizations. Think Slack — each company has its own workspace. Users from Company A can't see Company B's messages. Same app, separate spaces.

This is called multi-tenancy. The analogy is an apartment building. Everyone lives in the same building (uses the same app), but each apartment (organization) is completely separate. You can't walk into your neighbor's apartment.

In the database, you add an organization_id to almost every table. Every query filters by that organization. When Alice from Company A loads her messages, the app only fetches messages where organization_id matches Company A.

Chapter 11: File Uploads

Users want to upload things. Profile pictures. Documents. Images for their posts. Resumes. Receipts.

Here's the key insight: files don't go in the database.

Your database stores text, numbers, and dates. It's terrible at storing files. It would be like stuffing a filing cabinet with actual photos and binders — it gets bloated and slow fast.

Instead, files go in a storage service — a separate place designed specifically for storing files. Your database just stores the URL (the address) of where the file ended up.

Storage service options:

• Amazon S3 — the original. Used by most companies. Very reliable. Pay for what you use.
• Cloudflare R2 — like S3 but cheaper (no fees for people downloading files). Great for images.
• Supabase Storage — comes with Supabase. Simple setup. Good free tier.
• Uploadthing — built specifically for Next.js apps. The easiest to set up.

They all do the same thing: store your files and give you a URL. Pick whichever one your AI knows best (usually S3 or Supabase Storage).

Image resizing.

When someone uploads a 4000x3000 pixel photo as their profile picture, you don't want to serve that full image every time. It's slow and wastes bandwidth. You want to resize it — create a smaller version (like 200x200) for the profile picture, and maybe a medium version for other uses.

You can do this on upload (resize before storing) or on-the-fly (resize when someone requests the image). Both work. The AI can set up either approach.

Chapter 12: Sending Emails

Real apps send emails. Not the marketing kind (though that too) — the "your order shipped" kind, the "here's your password reset link" kind, the "someone commented on your post" kind.

These are called transactional emails — they're triggered by something the user did. They're not spam. They're expected.

You don't send emails from Gmail.

If you tried to send 1,000 emails from your personal Gmail, Google would shut you down within an hour. They'd think you're a spammer.

Instead, you use an email sending service — a company whose entire job is sending emails reliably. They have relationships with email providers (Gmail, Outlook, Yahoo) and know how to get your emails into inboxes instead of spam folders.

Options:

• Resend — modern, developer-friendly. Very easy to set up. Great free tier (100 emails/day).
• SendGrid — been around forever. Very reliable. Free tier of 100 emails/day.
• Postmark — focused on transactional email. Great deliverability (meaning your emails actually arrive). Fast.
• Amazon SES — cheapest at scale. More complex to set up.

For starting out, Resend is the easiest. It takes about 5 minutes to set up.

Transactional vs. marketing email.

Transactional — triggered by user actions. Password resets, order confirmations, welcome emails, notifications. Users expect these. You don't need permission to send them (they triggered the action).

Marketing — newsletters, promotions, announcements. Users must opt in. You need an unsubscribe link. This is legally required in most countries. Use a different service for this (like Mailchimp or ConvertKit).

Don't mix them. Transactional emails should always arrive instantly. Marketing emails can be batched. If you send marketing emails through your transactional service and get marked as spam, your password reset emails stop arriving too.

Email templates.

Nobody writes email content in code every time. You create templates — reusable designs with placeholders. Think of them like Mad Libs:

"Hi [NAME], your order #[ORDER_NUMBER] has shipped! Track it here: [TRACKING_URL]"

The AI fills in the blanks when sending.

Chapter 13: Search and Filtering

Every app with a list needs search. Users table? You need to search by name or email. Products page? You need to filter by category and price. Blog? You need to search by title and content.

Basic search: just check if the text contains the search term.

This is the simplest approach. The user types "banana" and you look for every product where the name contains "banana." It works. It's fast enough for small datasets (under 10,000 items).

Advanced search: full-text search.

When your data gets bigger or you need smarter matching (searching for "running shoes" should also find "jogging sneakers"), you need full-text search. PostgreSQL has this built in. For even more power, there are services like Algolia or Meilisearch that make search blazing fast and smart.

Filtering: narrowing the list.

Search finds items by text. Filtering narrows the list by attributes. "Show me products that are under $50 AND in the Electronics category AND have 4+ stars." Each filter is a condition. Stack them up.

Sorting: putting results in order.

By date (newest first), by price (low to high), by name (alphabetical), by popularity. Users expect to be able to sort. It's one dropdown.

Pagination: showing 20 at a time, not 10,000.

If your database has 50,000 products, you don't load them all at once. That would crash the browser and take forever.

Instead, you load a page at a time. Page 1 shows items 1–20. Page 2 shows items 21–40. And so on. This is called pagination.

There are two styles:

• Traditional — numbered pages (Page 1, 2, 3… like Google search results)
• Infinite scroll — loads more as you scroll down (like Instagram or Twitter)

Both are fine. Traditional pagination is easier to implement and better for most use cases.

Chapter 14: Admin Dashboards

You built the app. Users are signing up. Now you need to see what's happening. How many users signed up today? Are there posts that need moderation? Did any payments fail?

Every real app needs an admin view. It's not for your users — it's for you.

What admins typically see:

• Overview stats — total users, new signups today, revenue this month, active subscriptions
• User management — list of all users, ability to search, view details, change roles, suspend accounts
• Content management — all posts/products/items, ability to edit or remove them
• Payment info — recent transactions, failed payments, subscription stats
• System health — recent errors, API response times, database size

The simple approach: an /admin route.

You don't need a fancy separate app for your admin dashboard. Just create a section of your existing app at /admin that's only accessible to users with the admin role.

Inside that section, build pages with tables showing your data. A users table with columns for name, email, signup date, plan, status. A payments table showing recent transactions. A simple dashboard with numbers and maybe a chart or two.

Charts and stats.

Numbers are good. Charts are better. A line chart showing signups over the past 30 days tells a story that a raw number can't. A bar chart showing revenue by month gives you trends at a glance.

Libraries like Chart.js or Recharts make charts easy to add. The AI can wire them up quickly.

Content moderation.

If your app has user-generated content (posts, comments, reviews, images), you need a way to review and remove inappropriate content. This can be as simple as a "reported content" queue that shows items users flagged, with approve/remove buttons.

Chapter 15: Security Essentials (The Big 5)

Security is a deep field. People spend entire careers on it. But you don't need to be a security expert. You just need to get the Big 5 right. These cover the vast majority of what matters for a real app.

1. Hash passwords.

We covered this in Chapter 3, but it's worth repeating because it's that important. Never store passwords as plain text. Use a hashing library (bcrypt, argon2). The AI will do this by default with any decent auth library, but double-check.

2. Use environment variables for secrets.

Your API keys, database passwords, Stripe secret keys — these should NEVER be in your code. They go in a .env file that is NOT committed to Git (add .env to your .gitignore file).

Think of it this way: your code is the blueprint for a house. Anyone can see the blueprint. Your .env file is the key to the front door. Only you have it.

3. Validate all input.

Never trust anything that comes from a user. If your form asks for an email, check that it's actually an email. If it asks for a number, check that it's actually a number. If it asks for a name, check that it's not 50,000 characters of garbage.

This protects you from SQL injection — the most common database attack. It's like this: imagine you have a suggestion box at a restaurant. Normal people write suggestions. But someone writes: "Close at 5 PM; also give me all the money in the register." If your restaurant just does whatever the note says without reading it first, you're in trouble.

SQL injection works the same way. A malicious user puts database commands into a form field, hoping your app will run them. Validating input — and using an ORM instead of raw SQL queries — prevents this.

4. Use HTTPS.

HTTPS is the secure version of HTTP. It encrypts everything between the user's browser and your server. Without HTTPS, anyone on the same WiFi network can see what your users are doing.

Good news: any modern hosting platform (Vercel, Railway, Fly.io) gives you HTTPS automatically. If you're using a custom domain, you'll need an SSL certificate — but your hosting platform usually handles that too.

5. Keep dependencies updated.

Your app uses lots of libraries written by other people. Sometimes those libraries have security bugs. Updates fix those bugs. Run your package manager's update command regularly. For JavaScript, that's npm audit. For Python, that's pip audit or safety check.

CORS — keeping the doors closed.

CORS (Cross-Origin Resource Sharing) is a security rule that prevents random websites from making requests to your server. Imagine if any website could make requests to your banking API. That would be bad. CORS says: "only allow requests from MY website."

The AI will set up CORS for you, but know this: if you see a CORS error in the browser, it usually means you need to add your frontend's URL to your backend's allowed origins list.

Rate limiting — preventing abuse.

Rate limiting means: one person can only make X requests per minute. This prevents someone from hammering your server with millions of requests (a DDoS attack) or trying thousands of passwords (a brute force attack).

A simple rule: 100 requests per minute per user for normal endpoints, 5 per minute for login attempts.

Chapter 16: Error Handling

Things will go wrong. The database will be temporarily unreachable. A user will submit a form with missing data. Stripe will be down for 30 seconds. An image upload will fail because the file is too big.

The question isn't whether things go wrong. It's how your app behaves when they do.

User-facing errors: be friendly, not cryptic.

When something goes wrong, the user should see a clear, helpful message. Not "Error 500: Internal Server Exception." Not a blank white page. Not a wall of red text.

Good error messages:

• "Something went wrong. Please try again." (for unexpected errors)
• "That email is already registered. Try logging in instead." (for specific known errors)
• "Your file is too large. Maximum size is 5MB." (for validation errors)

The pattern is simple: tell them what happened, and tell them what to do about it.

Logging: keeping a diary.

When something goes wrong, you need to know about it — even if the user just sees a friendly message. That's what logging is.

Your app writes notes to a log file (or a logging service) every time something interesting happens. Not just errors — important events too. "User 42 signed up." "Payment of $29 processed." "Image upload failed: file too large."

Think of it as keeping a diary for your app. When something goes wrong, you read the diary to figure out what happened.

Error tracking: knowing about problems before users complain.

Logging is great, but who reads log files all day? Nobody. That's where error tracking services come in.

Sentry is the most popular. It automatically catches errors in your app and sends you a notification. It groups similar errors together, shows you exactly which line of code caused the problem, and tells you how many users are affected.

It's like having a smoke detector for your app. You don't stand in every room sniffing for smoke — the detector alerts you.

Error boundaries: one room on fire, rest of house fine.

In a real app, one feature crashing shouldn't take down the whole app. If the chat widget breaks, the rest of the page should still work. If the search bar errors out, the user should still see the page content.

This is called an error boundary. It wraps a section of your app and says: "If anything inside this section crashes, show a fallback message instead of breaking the entire page."

Think of it like fire doors in a building. If a fire starts in one room, the fire doors keep it from spreading. The rest of the building is fine.

Chapter 17: Deploying for Real

You deployed your toy app. Maybe you put it on Vercel or Railway. It worked. Someone could visit the URL and see it.

But deploying a real app is different. A real deployment means it stays up, it's secure, and you can update it without breaking things.

Environment variables in production.

Your .env file works locally. In production, you set environment variables through your hosting platform's dashboard. Every hosting platform has a settings page where you paste in your keys. The code reads them the same way — it doesn't know or care whether they come from a .env file or a hosting platform setting.

Never upload your .env file to production. Set each variable individually through the dashboard.

PostgreSQL in production (not SQLite).

If you've been using SQLite for development, you MUST switch to PostgreSQL for production. SQLite can't handle multiple users accessing the database simultaneously. Every hosting platform offers managed PostgreSQL:

• Supabase — generous free tier, great dashboard
• Neon — serverless PostgreSQL, free tier with autoscaling
• Railway — one-click PostgreSQL, included in your project

Set up a production database and put its connection string in your production environment variables.

Custom domain + SSL.

Your app is running at something like my-app-abc123.vercel.app. That's fine for testing. For a real product, you need your own domain (myapp.com).

Steps:

1. Buy a domain (Namecheap, Google Domains, Cloudflare)
2. Point it to your hosting platform (they'll tell you what DNS settings to use)
3. Enable SSL (HTTPS) — most platforms do this automatically

This takes about 15 minutes and costs $10–15/year for the domain.

CI/CD: auto-deploy when you push.

CI/CD stands for Continuous Integration / Continuous Deployment. It's a fancy name for a simple idea: every time you push code to GitHub, your app automatically deploys the new version.

Think of it like a conveyor belt in a factory. You put something on the belt (push code to GitHub), and it automatically goes through quality checks (tests run) and ends up packaged and shipped (deployed to production).

Most platforms (Vercel, Railway, Fly.io) do this automatically when you connect your GitHub repo. Push code, wait 60 seconds, and the new version is live.

Staging environment: test before it's real.

A staging environment is a copy of your production app that only you can see. It has its own database, its own URL, its own environment variables. It's identical to production — but it's not public.

Before you deploy a big change to production, you deploy it to staging first. Test it. Make sure it works. Then deploy to production with confidence.

Think of it as a dress rehearsal before opening night. Same stage, same costumes, same script — but no audience yet.

Database backups.

Your database is the most important part of your entire app. If your code disappears, the AI can help you rewrite it. If your database disappears, your users' data is gone forever.

Set up automated backups. Most managed database providers (Supabase, Neon, Railway) include automatic daily backups. Verify that they're turned on. Some let you do point-in-time recovery — meaning you can restore your database to exactly how it was at 3:47 PM last Tuesday. That's worth paying for.

The deployment checklist.

Before you launch, walk through this:

• PostgreSQL database set up (not SQLite)
• All environment variables set in production
• .env file is in .gitignore (not in repo)
• HTTPS / SSL is enabled
• Custom domain is configured
• Database backups are turned on
• Error tracking (Sentry) is set up
• Rate limiting is enabled on login/signup
• All passwords are hashed (not plain text)
• CORS is configured for your domain only
• User input is validated on every endpoint
• Payment webhooks are connected (if applicable)
• Email sending is tested and working
• Admin account is created
• CI/CD auto-deploy is connected to GitHub
• Staging environment exists and works
• Someone besides you has tested the app

Print out that checklist. Go through it item by item. If anything is unchecked, ask the AI to help you fix it before you launch.

That's the first half. You now know how to add authentication, payments, real database design, file uploads, emails, search, admin dashboards, security, error handling, and production deployment to your app.

In Part 2 of this guide, we'll cover: real-time features (WebSockets, live updates), background jobs, testing, performance optimization, mobile considerations, analytics, and scaling — plus a complete walkthrough of building a real SaaS app from scratch.

You already know more than most people who call themselves "vibe coders." The difference between a toy and a product is just these layers. And now you know what they are.

Keep building.

Chapter 18: Chrome Extensions

Your web app is a restaurant. People have to come to you. A Chrome extension is a delivery service — it brings your product to where users already are.

Chrome extensions are small programs that live inside the Chrome browser. You know that little row of icons in the top-right corner of Chrome? Those are extensions. Ad blockers, password managers, dark mode toggles — all extensions.

Here's the cool part: Chrome extensions are built with the same HTML, CSS, and JavaScript you already know. If you can build a web app, you can build a Chrome extension.

The anatomy of a Chrome extension:

Every extension has a few pieces. Think of it like a small team, each member with a job.

manifest.json is the ID card. It tells Chrome your extension's name, version, what permissions it needs, and what files to load. Every extension has one.

popup is the little window that appears when someone clicks your extension's icon. It's just a tiny web page — HTML, CSS, and a bit of JavaScript.

content script is code that runs on other people's websites. This is how ad blockers work — they inject code into every page you visit and hide the ads. Your content script can read page content, change how things look, or add buttons.

background script is the behind-the-scenes worker. It listens for events, manages state, and coordinates everything. It runs even when the popup is closed.

What can you build?

As a vibe coder, you can build surprisingly useful extensions:

• Productivity tools — highlight text on any page and save it, take screenshots, track time
• Page modifiers — change fonts, hide distractions, add dark mode to any site
• Data tools — scrape prices, track changes on pages, export tables to spreadsheets
• Quick-access dashboards — your app's key info, one click away
• AI assistants — select text on any page, right-click, get an AI summary or translation

Publishing your extension:

Getting your extension into the Chrome Web Store is straightforward.

1. Developer account — Sign up at the Chrome Web Store Developer Dashboard. It costs $5. One time. That's it.
2. Zip your files — Put all your extension files into a zip file.
3. Upload — Go to the dashboard, click "New Item," upload the zip.
4. Listing — Add a description, screenshots, and an icon. Just like an app store listing.
5. Review — Google reviews it. Takes 1–3 days usually. They check for malware and policy violations.

Once it's live, updating is easy. Change your code, bump the version number in manifest.json, upload a new zip. Users get the update automatically.

Chapter 19: Mobile Apps (App Store and Google Play)

Here's a secret that would have saved a lot of people a lot of money: you do NOT need to learn Swift or Kotlin to put your app on phones.

There are three paths. Each has trade-offs.

Path 1: PWA (Progressive Web App)

Think of this like giving someone your restaurant's website and saying "bookmark this on your home screen." A PWA is your existing web app with a few upgrades that let it install on a phone like a real app.

You add a small file called a "service worker" (it caches your app so it works offline) and a "manifest" file (it tells the phone your app's name and icon). That's basically it.

• Cost: Free. Zero dollars.
• App store: None needed. Users install directly from your website.
• Works on: iPhone and Android.
• Limitations: No push notifications on older iPhones. Can't access some phone features. Some users don't trust apps that aren't in the store.

Path 2: React Native / Expo

This is like opening a restaurant location inside a shopping mall. You get the foot traffic, the credibility, and the real estate — but you follow their rules.

React Native lets you write one codebase that runs on both iPhone and Android. Expo is a toolkit that makes React Native much easier. You write code that looks a lot like web development, and it produces real native apps.

• Cost: App Store = $99/year. Google Play = $25 one-time.
• App store: Yes, real listings in both stores.
• Works on: iPhone and Android from one codebase.
• Limitations: Learning curve. Some phone features need extra setup.

Path 3: Capacitor

This is like taking your food truck and turning it into a permanent kiosk. You already have a working web app. Capacitor wraps it in a native shell so you can put it in the app stores.

• Cost: Same store fees as above.
• App store: Yes.
• Works on: iPhone and Android.
• Best for: When you already have a web app and just want it in the stores.

When to use each:

App Store traps to know about:

• Apple's 30% cut — Apple takes 30% of any digital purchases made inside your app. Physical goods are fine. But if you sell subscriptions, premium features, or digital content through the app, Apple wants their cut. And you MUST use Apple's payment system.
• Review times — Apple reviews every update. Takes 1–7 days. They can reject you for weird reasons. Google is faster and more lenient.
• Privacy policy required — Both stores require a privacy policy URL. AI can write one, but have a lawyer check it.
• Screenshots required — You need screenshots in specific sizes for each device type.

Chapter 20: Desktop Apps

Most people don't need a desktop app. Web apps work great for almost everything.

But sometimes you do. Maybe your app needs to work offline. Maybe it accesses local files. Maybe your users expect a desktop experience — think design tools, code editors, or music software.

Here's the twist: you already know how to build one.

Electron — The Web Developer's Shortcut

VS Code? Built with web tech. Slack? Web tech. Discord? Web tech. Figma desktop? Web tech.

Electron takes your HTML, CSS, and JavaScript and wraps them in a desktop window. Your web app becomes a Mac app, a Windows app, and a Linux app. Same code.

The trade-off: Electron apps are big. Like, 100MB+ big. Because each one ships its own copy of the Chrome browser inside it. Users don't love that. But it works, and it's the fastest path from web app to desktop app.

Tauri — The Lighter Alternative

Tauri does the same thing as Electron but uses the computer's built-in browser engine instead of shipping Chrome. Result: apps are tiny (under 10MB) and faster. The trade-off is it's newer and has a smaller community.

How people get your desktop app:

Two options:

1. Direct download — Put a download link on your website. Users download and install it. Simple. You handle updates yourself.
2. App stores — Mac App Store or Microsoft Store. More visibility, automatic updates, but Apple/Microsoft take a cut and review your app.

For most vibe coders, if your app works great in the browser, keep it there. Desktop apps add complexity. But if your users need offline access or deep system integration, now you know the path.

Chapter 21: Landing Pages That Convert

Before anyone uses your app, they see a page. One page. And they decide in about 5 seconds whether to stay or leave.

That page is your landing page. It's not your app. It's the advertisement for your app. Think of it as the front window of a store. People glance in, and either walk in or walk past.

The anatomy of a landing page that works:

• Headline — The biggest benefit in one sentence. Not what your app does. What it does FOR THEM. "Save 5 hours a week on invoicing" beats "AI-powered invoice management platform."
• Problem — Show them you understand their pain. "You know how you spend every Sunday evening doing your bookkeeping?"
• Solution — Now introduce your app. Keep it simple.
• Social proof — Testimonials, user counts, logos of companies using it. Even "Used by 50 people" is better than nothing.
• CTA (Call to Action) — The button. "Start free" or "Try it now." One clear action. Not five options.

SEO — How Google finds you

SEO stands for Search Engine Optimization. It's just: making Google understand what your page is about so it shows up when people search for related things.

Think of Google as a librarian. Your page is a book. SEO is making sure the librarian knows the title, the topic, and where to shelve it.

The basics:

• Title tag — The title that appears in Google search results. Put your main keyword in it.
• Meta description — The short summary under the title in Google. Write something compelling.
• Headers — Use H1, H2, H3 tags properly. Google reads them to understand your page structure.
• Sitemap — A file that lists all your pages. It's like giving the librarian a table of contents.

Open Graph tags — How your link looks on social media

When someone shares your link on Twitter or LinkedIn, those tags control what image, title, and description appear. Without them, shared links look ugly and get fewer clicks.

Chapter 22: Email Marketing With AI

Social media followers aren't yours. Instagram could change its algorithm tomorrow and nobody sees your posts. But an email list? That's yours. Nobody can take it away.

Step 1: Build your list.

Add a signup form to your landing page or app. Offer something free in exchange for their email — a guide, a template, a free trial. This is called a "lead magnet." It's bait. Good bait.

Step 2: Pick a tool.

Start with whatever has a free tier that fits your needs. You can switch later.

Step 3: Welcome sequence.

When someone signs up, don't just say "thanks." Send them a series of 3-5 emails over the next week. This is called a "drip campaign" — like a slow drip of water instead of a firehose.

A simple welcome sequence:

1. Day 0 — Welcome! Here's what to expect.
2. Day 1 — Here's the thing you promised (lead magnet).
3. Day 3 — A quick tip about [your topic].
4. Day 5 — How other people use [your product].
5. Day 7 — Ready to try the full thing? (CTA)

Chapter 23: Social Media and Content With AI

Here's the content creation cheat code: write ONE thing, then slice it into many things.

Write one blog post. Turn the key points into 5 tweets. Summarize it for a LinkedIn post. Pull out the best tip for an Instagram caption. Rewrite the intro as a newsletter opener.

One piece of content. Five platforms. This is called "repurposing," and AI makes it almost effortless.

AI for writing

Blog posts, Twitter threads, LinkedIn articles, product announcements — AI can draft all of them. You add the ideas and personality. AI handles the structure and first draft.

AI for images

You don't need a graphic designer for every social media post.

• Midjourney / DALL-E — Generate custom images from text descriptions.
• Canva AI — Templates with AI-powered design suggestions. Great for social media graphics.

One session, one month of content. Spend a couple of hours with AI on a Sunday. Map out the whole month. Draft everything. Schedule it with a tool like Buffer or Typefully. Then get back to building.

Chapter 24: Customer Support With AI

Your first users will have questions. Some obvious. Some confusing. Some will find bugs you never imagined.

This is good. It means people are using your product.

Step 1: FAQ page.

Before you build anything fancy, write an FAQ page. Take every question anyone has ever asked you about your product, and answer it. AI is great at this.

Step 2: Chatbot.

A chatbot is a small chat window on your website that answers questions automatically. Think of it as a really patient employee who works 24/7 and never gets tired.

Options:

• Intercom — Full-featured, pricey, used by big companies.
• Crisp — More affordable, great free tier.
• Build your own — If your app already uses AI, you can build a simple chat widget that uses your FAQ as context.

Step 3: Email support templates.

When people email you directly, AI helps you respond fast and consistently.

Step 4: Knowledge base.

As you grow, upgrade your FAQ into a full help center. Organized by category. Searchable. With screenshots and step-by-step guides.

Chapter 25: Operations and Automation

Running a business has a lot of repetitive tasks. Sending invoices. Writing weekly reports. Cleaning up data. Following up with leads. Drafting contracts.

AI eats repetitive tasks for breakfast.

What AI can automate for you

• Invoices — AI generates professional invoices from a simple description: "Invoice for John, 10 hours of consulting at $100/hour."
• Weekly reports — Feed AI your metrics and it writes a summary for your team or investors.
• Data cleanup — Messy spreadsheet? AI normalizes names, fixes formatting, fills in blanks.
• Scheduling — AI drafts scheduling emails, suggests meeting times, writes agendas.
• Contract drafting — AI writes first drafts of simple contracts. Always have a lawyer review.

Connecting tools with Zapier/Make.com

Zapier and Make.com are like universal translators between apps. "When someone fills out my form, add them to my email list and send them a welcome message and create a task in my project board." No code needed.

Think of them as dominoes. You set up a chain. When the first one falls (a trigger happens), everything else follows automatically.

Chapter 26: Analytics and Monitoring

"Is anyone using my app?" is a question you'll ask every single day. Analytics answers it.

Analytics is just counting. How many people visited. How many signed up. How many came back. Which features they use. Where they leave.

Think of it like a restaurant owner watching the floor. How many people walk in? How many sit down? How many order? How many come back next week?

Tools

Start with Plausible if you care about simplicity and privacy. Start with Google Analytics if you want free and powerful.

Uptime monitoring

Your app will go down. It just will. The question is: do you find out from a monitoring tool or from an angry user?

UptimeRobot is free and checks your site every 5 minutes. If it goes down, you get a text or email. Set this up on day one.

The daily dashboard

Every morning, check three things:

1. Is the app up? (UptimeRobot)
2. Are people using it? (Analytics)
3. Are there errors? (Error logs)

Chapter 27: Market Research With AI

The biggest mistake you can make is building something nobody wants. It happens all the time. Someone spends six months building the perfect app, launches it, and... crickets.

Don't be that person. Validate before you code.

Step 1: Is anyone actually looking for this?

Step 2: Competitive analysis.

Find out who else does what you want to do. Not to copy them — to find the gaps.

Step 3: TAM/SAM/SOM — How big is the opportunity?

These are investor buzzwords, but the concept is simple. Think of pizza.

• TAM (Total Addressable Market) = Everyone in the world who eats pizza. The theoretical maximum.
• SAM (Serviceable Addressable Market) = Everyone who eats pizza in your city. The people you could realistically reach.
• SOM (Serviceable Obtainable Market) = Everyone within your delivery range who would order from you. The people you'll actually get.

If your TAM is "all small businesses" but your SOM is "freelance designers in the US who use Figma," that's fine. Start specific.

Step 4: Talk to real people.

This is the step everyone skips, and it's the most important one. Talk to 10 people who would use your app. Not your friends. Not your mom. People who have the problem you're solving.

Chapter 28: Finding Co-Founders

Do you need a co-founder? Not always. Plenty of successful companies were built by one person. Plenty of others were built by two or three.

The question is: do you have a skill gap that's holding you back?

If you're a vibe coder who can build the product but can't sell it, you might need a co-founder who's great at sales and marketing. If you can sell anything but can't build, you need a technical co-founder (but with AI, this matters less than it used to).

What to look for

• Complementary skills — You want someone who's strong where you're weak. Two people with the same skills is a waste.
• Same values — You'll disagree on tactics. That's fine. But you need to agree on the big stuff: what you're building, why, and how you treat people.
• Work ethic match — If one person works 60 hours a week and the other works 20, resentment builds fast.

Where to find co-founders

• Y Combinator's co-founder matching — Even if you don't apply to YC, their matching platform is good.
• Indie Hackers — Community of people building small businesses. Active forums.
• Meetups — Local startup events. Nothing beats meeting someone in person.
• Twitter/LinkedIn — Build in public, attract people who resonate with your work.

The co-founder agreement

Before you write a single line of code together, agree on the terms. In writing.

The most important concept: vesting with a cliff.

Here's the analogy. Imagine you and your co-founder split the company 50/50 on day one. Two months later, they quit. They still own 50% of a company you're building alone. That's a disaster.

Vesting fixes this. Instead of giving all the equity upfront, it's earned over time. The standard is 4-year vesting with a 1-year cliff.

• 4-year vesting = Your shares unlock gradually over 4 years. After year 1, you've earned 25%. After year 2, 50%. And so on.
• 1-year cliff = Nothing vests until you've been around for a full year. It's a trial period. If someone leaves in month 3, they get nothing.

This protects everyone.

Always get a lawyer to review. AI drafts. Lawyers protect.

Chapter 29: Pitching Investors

Let's be clear: not every product needs investors. Many incredible businesses were built without outside money. Basecamp, Mailchimp (for most of its life), Craigslist — all bootstrapped.

Taking investor money means giving up some control and ownership. It's not free money. It's a trade.

When you DO need funding

• Your product needs a lot of money upfront before it can make money (hardware, marketplace, etc.)
• Speed matters more than ownership (competitive market, network effects)
• You need to hire a team before revenue covers salaries

Funding stages — the ladder

At each stage, you give up a piece of your company. Pre-seed might take 5–10%. Seed might take 15–25%. Each round dilutes your ownership.

What investors look for

1. Big market — Is the opportunity large enough?
2. Strong team — Can these people actually pull it off?
3. Traction — Are real people using it? Paying for it?
4. Unique insight — Why will this team win where others haven't?

The 10-slide pitch deck

Almost every pitch deck follows this structure. Each slide is one idea.

1. Title — Company name, one-line description, your name
2. Problem — What sucks right now? Make them feel the pain.
3. Solution — How you fix it. Demo screenshot.
4. Market — How big is the opportunity? (TAM/SAM/SOM)
5. Product — How it works. Screenshots or quick demo.
6. Traction — Users, revenue, growth rate. Any numbers.
7. Business model — How you make money.
8. Competition — Who else is doing this? Why are you different?
9. Team — Who are you? Why are you the right people?
10. Ask — How much money, what you'll use it for.

Chapter 30: Runway, Budgets, and Making Money Last

Runway is your fuel gauge.

If your car has half a tank and you burn a quarter tank per trip, you have two trips left. Runway works the same way.

$30,000 in the bank. $5,000/month in expenses. That's 6 months of runway.

When you hit 3 months of runway, that's your warning light. Time to either make more money or raise more money.

How to calculate

Runway (months) = Money in bank / Monthly expenses

That's it. Update this number every month.

Typical expenses breakdown

Revenue models — how apps make money

• SaaS subscription — Monthly/yearly fee. Most predictable. Example: $19/month for Pro features.
• Freemium — Free version + paid upgrade. Gets users in the door. Converts 2–5% typically.
• One-time purchase — Pay once, use forever. Simple but no recurring revenue.
• Marketplace — Take a cut of transactions between buyers and sellers.
• Ads — Free product, show ads. Need lots of users to make real money.

Chapter 31: Legal Basics

This chapter isn't legal advice. It's a map so you know what exists and what to ask a real lawyer about.

Documents every app needs

1. Terms of Service (ToS) — The rules for using your app. What users can and can't do. What happens if things go wrong. Your liability limits.
2. Privacy Policy — What data you collect, how you use it, who you share it with. Required by law in most countries. Required by app stores. Required by ad platforms.
3. Cookie Policy — If your website uses cookies (most do), European law (GDPR) requires you to tell users about it.

AI drafts these in minutes. A lawyer reviews for $200–500. Don't skip the lawyer.

Incorporating your business

Two main options in the US:

• LLC (Limited Liability Company) — Simpler, cheaper, good for solo founders and small businesses. Protects your personal assets if the business gets sued. Costs $50–500 depending on the state.
• C-Corp — What investors expect. Required for venture capital. More paperwork, more rules, double taxation. But it's the standard for funded startups. Delaware is the most popular state to incorporate in (even if you don't live there) because their business laws are well-established.

If you're a solo founder just starting out, LLC. If you're raising money, C-Corp in Delaware.

Stripe Atlas — The easy button

Stripe Atlas costs $500 and does almost everything: incorporates your C-Corp in Delaware, gets you an EIN (your business's social security number), sets up a bank account, and provides legal document templates. It's the "I don't want to deal with this" option, and it's worth it.

Chapter 32: Marketing Strategy With AI

AI is the best marketing co-pilot you'll ever have. It doesn't get tired. It doesn't have creative blocks. It's available at 2 AM when you suddenly have an idea.

Competitor research

Ad copywriting

Writing ads is hard. You have 3 seconds and a few words to grab attention. AI can generate dozens of variations in minutes.

A/B testing ideas

A/B testing means showing two versions of something to different people and seeing which one performs better. Version A vs Version B.

Pricing experiments

Chapter 33: The Lifecycle of a Real App

Building the app is chapter one. Running it is the whole book.

Bug reports

Users will find bugs. That's fine. The process is always the same:

1. Reproduce — Can you make the bug happen on your end?
2. Fix — Find the broken code and fix it.
3. Test — Make sure the fix works and didn't break something else.
4. Deploy — Push the fix to production.

Feature requests

Users will ask for features. You can't build everything. Prioritize by asking:

• How many people asked for this?
• Does it align with where the product is going?
• How hard is it to build?
• Will it help retain users or attract new ones?

Technical debt

Think of technical debt like dishes piling up in the sink. You can ignore them for a day. Maybe two. But eventually, the kitchen becomes unusable. You have to stop cooking and just wash dishes for a while.

In code, technical debt is shortcuts you took. Messy code. Duplicate logic. Things that work but aren't organized well. Every app accumulates it.

The rule: if the mess is slowing you down, clean it up. If it's not, keep shipping.

When your app outgrows vibe coding

This happens. It's a good problem. Your app gets complex enough that AI-assisted vibe coding isn't enough. You need a real developer or a team.

Signs it's time:

• Changes take longer and longer because the code is tangled.
• You're afraid to change one thing because it might break another.
• Performance problems that require deep technical knowledge.
• Security requirements that need expert review.

Building a team — what roles come first

1. First hire: someone who covers your weakness. If you're technical, hire marketing. If you're marketing, hire technical.
2. Customer support — when you can't answer every email yourself.
3. A real developer — when the codebase needs someone with deep experience.

The journey continues.

You started by telling an AI to build you a button. Now you're running a product, serving users, making money, and thinking about your next hire.

That's not a small thing. Most people never ship anything. You did.

The tools will keep getting better. AI will keep getting smarter. The gap between "I have an idea" and "I have a product" will keep shrinking.

But the fundamentals don't change. Solve a real problem. Talk to your users. Keep shipping. Stay curious.

You've got this.

Appendix A: The Real Product Checklist

Build

• Validated the idea with real potential users
• Built an MVP (minimum viable product) with core features only
• Added user authentication (login/signup)
• Added payment processing (if charging money)
• Set up a database for user data
• Made the app mobile-friendly (responsive design)
• Added error handling (users see friendly messages, not crashes)
• Set up environment variables for secrets (API keys, passwords)
• Tested core user flows (signup, main action, payment)
• Added loading states and empty states

Ship

• Deployed to a hosting platform (Vercel, Railway, etc.)
• Connected a custom domain
• Set up SSL/HTTPS (usually automatic with hosting)
• Set up a production database
• Configured environment variables in production
• Tested the live app end-to-end
• Set up error logging in production

Launch

• Built a landing page with clear value proposition
• Added SEO meta tags and Open Graph tags
• Created a sitemap.xml
• Set up analytics (Plausible, PostHog, or Google Analytics)
• Set up uptime monitoring (UptimeRobot)
• Created social media accounts for the product
• Wrote and scheduled launch posts
• Prepared a launch email
• Submitted to Product Hunt, Hacker News, or Indie Hackers

Business

• Chose a business structure (LLC or C-Corp)
• Incorporated the business
• Got an EIN (business tax ID)
• Opened a business bank account
• Published Terms of Service
• Published Privacy Policy
• Published Cookie Policy (if using cookies)
• Set up accounting (Wave, QuickBooks, or spreadsheet)
• Understand tax obligations

Run

• Built a FAQ / help center
• Set up customer support channel (email, chat, or both)
• Created email templates for common support replies
• Set up automated email sequences (welcome, onboarding)
• Established a regular backup schedule
• Created a process for handling bug reports
• Set up a way to collect feature requests

Grow

• Defined key metrics and track them weekly
• Created a content calendar
• Built an email list
• Set up referral or word-of-mouth programs
• A/B tested landing page and onboarding
• Explored paid advertising (start small: $5-10/day)
• Collected and displayed testimonials
• Planned version 2 features based on user feedback

Appendix B: “Tell the AI” Prompt Collection

Building Features

Shipping to Platforms

Launching

Business & Legal

Running Operations

Growing

Appendix C: Service Comparison

Authentication Services

Payment Services

Email Services (Transactional)

Email Marketing

File Storage

Databases

Hosting

Analytics

Appendix D: Startup Costs Cheat Sheet

Bootstrap Tier ($0–100/month)

For people testing an idea with minimal investment.

Lean Tier ($100–500/month)

For products with paying users, getting serious.

Growth Tier ($500–2,000/month)

For products scaling with a real user base.