Lesson 03: Making Your App Production-Ready
Embark on your journey to building production grade apps.
You've built an app and shipped it to the internet. But "deployed" and "production-ready" are two very different things. This lesson is a quick overview of everything that goes into taking an app from demo to real product.
Your app works. But if a thousand people showed up tomorrow, things would break. If someone tried to abuse it, they could. If Google tried to find it, it wouldn't show up.
Production-ready means your app is polished, secure, reliable, and ready for real users. Here's everything you need to know exists.
Polish
Responsive design - your app needs to look good on phones, tablets, and desktops. Over half of all web traffic comes from mobile.
Favicon & page title - the little icon in the browser tab and the title that shows up in search results. Small details that make your app feel real.
Accessibility - making your app usable for everyone, including people with screen readers, keyboard navigation, or low vision. Required by law in many places.
Dark mode - reduces eye strain and saves battery. Users expect it.
Get Discovered
SEO - search engine optimization helps your app show up in Google.
Open Graph tags - control how your link looks when shared on Twitter, Discord, iMessage. Without them, shared links show a blank preview.
Analytics - tells you how many people visit, where they come from, and what they do. Without it, you're flying blind.
Custom domain - myapp.com instead of my-app.vercel.app. Makes it feel legit.
What do Open Graph tags do?
Real Features
This is where things get complex fast.
Database - your app can't remember anything right now. Refresh and everything resets. A database lets you store user data, content, and anything that needs to persist. Popular options: Supabase, Firebase, PlanetScale.
User authentication - letting people create accounts and log in. This includes password hashing, session management, OAuth (sign in with Google), email verification, and password resets. Never build this from scratch.
File storage - if users upload images or documents, you need cloud storage. Files saved to your server get wiped on every deploy. Popular options: Supabase Storage, AWS S3, Cloudflare R2.
Payments - if you want to charge money, you need a payment processor like Stripe. They handle credit cards, taxes, receipts, refunds. They take about 3% per transaction and can freeze your account.
Email & notifications - welcome emails, password resets, order confirmations. You need a service like Resend or SendGrid to send these programmatically.
Why should you never build user authentication from scratch for a real product?
Infrastructure
Environment variables - API keys and secrets should never be in your code or on GitHub. Bots scan GitHub constantly and will find exposed keys within minutes.
CI/CD - your app automatically builds, tests, and deploys every time you push code. Vercel does this by default.
Staging environments - a copy of your production app where you test changes before they go live.
Why should API keys go in environment variables and never in code committed to GitHub?
Reliability
Error handling - without it, your app shows a blank white screen when something breaks. Users should always know what's happening.
Error tracking - tools like Sentry tell you what went wrong in production, which user hit the error, and what they were doing.
Testing - code that checks if your other code works. Unit tests, integration tests, end-to-end tests. Start with the parts that would hurt most if they broke.
Backups - if you have a database, you need backups. Databases get corrupted, accidentally deleted, or hit by bad migrations.
Security
HTTPS - encrypts traffic between users and your app. Automatic with Vercel and GitHub Pages.
Input validation - never trust user input. Sanitize everything. SQL injection and XSS attacks let attackers steal data or hijack your app.
Rate limiting - prevents someone from hammering your API with thousands of requests. Without it, one bad actor can take your app down or rack up your costs.
And a lot more - e.g. data encryption to protect your website.
What does rate limiting prevent?
Performance
Image optimization - compress images, use modern formats (WebP/AVIF), serve the right size for each screen.
Caching - store copies of data so you don't fetch it every time. Browser caching, server caching, CDN caching.
Core Web Vitals - Google's metrics for page speed and user experience. They directly affect your search ranking.
Legal
Privacy policy - legally required if you collect any user data.
Terms of service - required if users create accounts.
Cookie consent - required if you use tracking and your users are in Europe (GDPR).
The Big Picture
That's a lot. And nearly every single item on this list is a separate service, a separate account, a separate thing that can break. This is the reality of building production-grade software with traditional tools.
In the next lesson, we'll introduce a fundamentally different approach. You'll learn how many of these problems (identity, data storage, payments, trust) can be solved using distributed systems.
0/4 correct
0% — get all correct to complete