Ship It

The pre-launch checklist. What actually needs to work before you send someone the link.

There is a gap between what works in your development environment and what works in production. Understanding this gap is the difference between a prototype and a product.

The production gap

That said, this table is not an excuse to delay. You do not need to solve all of these before your first user sees the product. You need to solve exactly one: getting it online so someone can use it.

Three architecture patterns

Most AI products fit one of these patterns. Pick the simplest one that works for your use case:

Synchronous. User sends a request, waits for the response, gets it back. Simple, works for anything that responds in under 30 seconds. This is where you start.

Streaming. Tokens are delivered as they're generated. The user sees words appearing in real time instead of staring at a spinner. Use this for chat interfaces and long responses. It makes slow responses feel fast.

Async / queue-based. The request goes into a queue, gets processed in the background, and the result is delivered later (via polling, webhook, or notification). Use this for long processing, batch operations, or when reliability matters more than immediacy.

What you actually need before your first user

The minimum viable production setup:

• Your code on the internet. Not your laptop. A real URL someone can visit. Here's how to do that in under an hour.
• API keys in environment variables. Never in your code, never in your repository. Your hosting provider (Vercel, Railway, etc.) has a settings panel for this.
• Error handling for API failures. The AI provider will go down. Your app should show a useful message when it does, not a blank screen.
• A spending limit on your AI provider account. Both OpenAI and Anthropic let you set hard caps. Set one. A bug in your code should not result in a $500 bill.

That's it. Not logging, not monitoring dashboards, not canary deployments. Those matter later. Right now, getting the product in front of a real person matters more than any of them.

What to add after your first 10 users

Once real people are using the product, you'll discover what actually breaks. Then you add:

• Basic logging. What are people asking? What is the model responding? You need to see this to improve your prompts. Be thoughtful about what you log, and tell your users what you collect.
• Error tracking. A service like Sentry catches errors automatically and emails you. Free to start. You'll know about problems before your users tell you.
• Rate limiting. Protect against a single user (or a bot) burning through your API budget. Even a simple limit of 20 requests per minute per user is better than nothing.

What to add after your first 100 users

At this point, you're past survival mode and into optimization. This is when the rest of the engineering sections of this playbook become relevant:

• Cost tracking per feature and per user. Know your unit economics before you scale, not after.
• Model fallbacks. If your primary model goes down, route to a backup. Claude fails, try OpenAI. This is table stakes for reliability.
• Caching. If many users ask similar questions, save the response instead of generating it again. This can cut costs 30-50%.
• Deployment strategy. Canary releases (roll out changes to 5% of users first) or feature flags (toggle features without redeploying). Both reduce the blast radius of a bad change.

If your MVP is working and you're feeling the rush to scale, pause. Read Your MVP Worked. Now What? -- it covers the five questions to answer before you go from demo to production, and everything that breaks when the controlled conditions disappear.

---
description: Run a ship-readiness check on your project. Tells you what's actually blocking launch vs. what you're hiding behind.
---

You are a drill sergeant for shipping software. Your job is to get this product in front of real users TODAY, not next week, not after one more feature. Today.

First, scan the current project to understand what it does. Then run this checklist:

**Must-have (cannot ship without these):**
1. Does the app load without errors on a public URL? (Not localhost.)
2. Are all API keys and secrets in environment variables, not in the code?
3. Does the core feature work? (The ONE thing the product does.)
4. Does it work on a phone? (Open the URL on mobile.)

If ANY of these fail, fix that specific thing. Nothing else.

**Nice-to-have (ship without these):**
- User accounts and login
- Beautiful design
- Multiple features
- Settings pages
- Email notifications
- Analytics
- Error tracking
- A custom domain

That entire list can wait. Every item on it is a reason builders don't ship. None of them are reasons users won't try your product.

**The hard question:**
Ask the user: "When did you start building this?" If the answer is more than 2 weeks ago, say:

"You've been building for [X weeks]. That's long enough. The features you're adding now are not making the product better. They're making you feel safer. The market doesn't grade your code. It grades whether the thing helped. And you cannot learn that from your own laptop. Ship it. Fix what breaks. Here's how to get it live in under an hour: https://builderspath.dev/playbook/#get-it-live"

**If they're already live:**
"Good. Now go get someone to use it. Not a friend. A stranger. https://builderspath.dev/playbook/#find-your-first-users"