Chapter 5 of 5
Grow Without Falling Apart (i.e. scalability)
You need infrastructure sized for where you are, not where LinkedIn thinks you should be.
What you'll see developers say online
Developers bludgeon vibe-coded apps with scaling: as soon as you launch, it’ll fail at two or three clients. You can’t grow without enterprise infrastructure, DevOps, and an engineering team. They’ll say you need to build for a thousand customers on day one, or your app will collapse the moment you get real users.
The solution: scalability in plain language
Developers call it scalability. For you it’s one question: is your infrastructure sized for how many customers you have today, not how many LinkedIn thinks you might have someday? Scaling is hard only when you build for a thousand users while you have three. Most devs treat “scaled” and “unscaled” as opposites and overbuild to the extreme. What’s actually true: match hosting, database, and ops complexity to where you are now, and know what changes at the next milestone.
If you do this yourself
You move fast and stay nimble. Overbuilding now costs speed and complexity later. Simple wins, and you stay in control of your own product.
Developer perspective
Every developer has their own scaling preferences. There’s no one right answer. They’re still right that when load goes up, your systems shouldn’t fail immediately.
My Go To Prompts
I review codebases all the time. I’m a battle-tested CTO. I’ve built startups. Here are three prompts I use every day. These aren’t theoretical. They’re the actual prompts I run, tune, and build skills around.
1. Framing prompt
Your starting point. Scalability sounds like it requires a DevOps team and years of infra war stories, but it is a set of decisions you can make step by step. This tells the AI who to be so the rest of the conversation stays grounded in your customer reality, not LinkedIn architecture porn.
Follow-up questions you can ask
Paste these after the framing prompt to tease out what scalability means for your app. Still no migrations or code changes.
-
Priority
Why does right-sized infrastructure matter for my app right now, given my customer count, usage pattern, and go-to-market? -
If you skip
What happens if we overbuild now, or ignore scaling until something breaks? What do we burn (money, speed, control), and when would a senior dev use that against us? -
Scaling building blocks
Walk me through the core scaling building blocks (hosting, database, caching, background work, CDN/edge) in plain language. For my app, where would each matter first and where would it be overkill at our stage? -
Right-size it
With our current customers and release pace, what is the minimum infra stack that still looks professional, and what should we explicitly not build for “a thousand users on day one”?
2. Current state prompt
Use this after the framing prompt. You are not asking the AI to migrate hosts or resize databases yet. You are building a picture of how the app runs today and what would strain first as you grow. That stops panic re-architecture and helps you learn what scalability actually means for your business. Expect a table you can read and push back on with follow-up questions.
Follow-up questions you can ask
Paste these after you have the table. Same chat, still no migrations or code changes. They push into vendor and growth details a senior reviewer would ask about.
-
Customer reality
Based on my ICP and usage, how many concurrent users or customers should we actually plan for in the next 90 days, not the next five years? Where is our table assuming fantasy load? -
Hosting fit
Is our current host (Fly, Railway, Render, Cloudflare, GitHub Pages, AWS, etc.) right-sized, or are we on a sledgehammer for a thumbtack? Compare cost, complexity, and who can operate it (me vs. a hire). -
Overbuild risk
Which rows in your table are enterprise overkill for our stage, and which are underbuilt in a way that would embarrass us at the next five customers? -
Cost and burn
Where could we surprise ourselves on the cloud bill if usage doubles? Flag fixed vs. variable cost and the first metric we should watch. -
Next milestone
What changes at 10 customers, 100, or 10x traffic, specifically for this stack? Give me a ordered list of “when X happens, do Y”. Still no implementation. -
If we skip it
For the lowest-scored rows, what happens if we skip them for the next 30 days: what fails first, and when would growth kick us out of our own product?
3. Capture the Wins and Patterns
Run this when you are ready to save what you learned. It creates a markdown file in your project root so the next scaling conversation picks up where you left off. You are not re-explaining your customer count and stack from scratch every time.
Follow-up questions you can ask
Use this if you decided on new patterns or priorities after the file was created. Same chat.
-
Update priorities
Take any patterns, milestones, or priorities I outlined in our conversation and add or update them in scalability-status.md. Keep the file aligned with what I have decided matters for how we grow.
What you get
If you use this, you will have a scaling plan that matches your customer count and usage, not an AWS architecture diagram you cannot operate. You will know what you are running, what breaks first as you grow, and what to add next. That turns off the “it will collapse at three clients” bludgeon, because you can explain how you grow on purpose.
Fly.io is how I host when I want servers that scale without the AWS tax. Hobby tier is free. Real servers run around six bucks. Multi-region lives in config. Right-sized for where you are today, not where LinkedIn thinks you should be.
Fly.io - Low-Code Playbook →
Fly for the app. Surge.sh when you need a static page live in two commands before the meeting ends. Weird double. Works. Both sit in my fractional playbook because vibe-codable hosting beats enterprise ceremony at this stage.