Question 1

How do I securely store API keys and secrets in a web app?

Accepted Answer

Every app you build talks to other services — Stripe for payments, OpenAI for AI, your database for data. Each of those gives you a long secret string (an API key) that proves it's you. If those strings are sitting inside your code, anyone who looks at your code can use them. That includes anyone you accidentally share a screenshot with, anyone you push to GitHub, and anyone who gets into your builder account. This is the #1 way vibe-coded apps get destroyed. One leaked OpenAI key can rack up thousands of dollars over a weekend. One leaked Stripe key can let someone refund every charge you've ever made. Every modern builder gives you a place to store these safely — usually called "Secrets," "Environment Variables," or ".env" — you just have to use it.

Question 2

What does secure authentication look like for a small launch?

Accepted Answer

How users sign in, receive verification codes, recover paid access, and stay signed in. Done well, only the real user can get into their account. Done badly, an attacker can guess codes, enumerate customers, abuse SMS/email delivery, steal sessions, or read passwords straight out of your database. If your login or OTP flow is weak, every other security thing you did doesn't matter — the attacker just walks in the front door or your paid users get locked out. The good news: you almost never need to build login from scratch. Use a proven provider and let shippingszn scan for the launch risks AI builders usually miss.

Question 3

How do I protect a web app against common attacks like XSS, CSRF, and SQL injection?

Accepted Answer

There are a handful of attacks that bots constantly run against every site on the internet. They have ugly names — XSS, SQL injection, CSRF — but the idea is simple: they trick your app into running code or queries it shouldn't. Modern frameworks have built-in defenses; you just have to use them correctly. These bots don't care who you are. They scan the entire internet looking for sites that forgot to defend. If yours is one of those, your data ends up dumped on a forum, your users get hijacked, and you find out by reading about yourself online.

Question 4

Which HTTPS and browser security headers should every new app ship with?

Accepted Answer

HTTPS is the little padlock in the browser bar. It encrypts everything between your user and your server, so people sharing the same WiFi can't read passwords as they're being typed. Security headers are extra instructions you send to the browser saying “never trust content claiming to be from me unless it really is.” Without HTTPS, anyone on the same coffee-shop WiFi can read your users' passwords as plaintext. Without security headers, attackers can wrap your site inside theirs (clickjacking) or trick browsers into running malicious scripts. The fixes are basically free.

Question 5

How do I separate development and production data safely?

Accepted Answer

Two databases: one to mess around with while you build (development), one that holds your actual users' actual data (production). They should never touch each other. Most modern builders and hosted database services (Replit, Supabase, Neon, PlanetScale) set you up with both automatically when you publish. If you point a half-broken in-progress feature at the real database, you can corrupt or wipe real user data with one bad query. If you copy real user data into your dev environment, you've taken a privacy obligation and made it more likely to leak. Keep them apart.

Question 6

Do I really need terms of service and a privacy policy at launch?

Accepted Answer

Two pages most apps need: Terms of Service (the rules of using your app) and a Privacy Policy (what data you collect and what you do with it). They are legal documents — the words matter, and they have to actually describe what your app does. These protect you from getting sued and protect your users from being misled. Most platforms (App Store, Google, Stripe, even Google sign-in) require them. Generated or copy-pasted policies that don't match your actual product are worse than nothing — they're evidence in a lawsuit.

Question 7

What error monitoring should I have set up on day one?

Accepted Answer

Error monitoring is software that sits inside your app and silently records every error, then alerts you. So when your user hits a bug at 2am, you know about it within minutes — instead of hearing about it three days later from a frustrated tweet. Most users do not report bugs. They just leave. By the time you find out something is broken from feedback, dozens of people have already bounced. With error monitoring, you see problems immediately and can fix them before they spread.

Question 8

What SEO basics should every new web app ship with?

Accepted Answer

Tiny bits of metadata in your HTML that tell Google what each page is about, and tell Twitter, LinkedIn, Slack, and iMessage how to display a preview when someone shares your link. These are your free billboards. A page with no title gets no clicks in Google. A link in iMessage with no preview image looks broken or sketchy. You only have to do this once per page.

Question 9

How do I make my site citeable by AI answer engines like ChatGPT and Google AI Overviews?

Accepted Answer

More and more people ask ChatGPT, Perplexity, or Google's AI Overviews instead of clicking through search results. Those AIs are pulling answers from websites — but only the ones structured in a way they can confidently quote. AEO is the work of making your site quotable. Search is shifting from "here are 10 links" to "here's the answer." If your content isn't structured for AI engines to extract, you're invisible to a fast-growing channel — even if your normal SEO is fine.