/scalability
v0.3 · Updated Sep 17, 2026
Scalability is a huge and potentially controversial topic if you sit down with a bunch of devs, because everyone thinks something different. I think about scalability as how to get to revenue, and address the customers, the volume of customers, and the demand at your current status point.
Kickoff prompt
Review this app for /scalability. How will it handle more traffic, meaning more business? Look at how and where it is hosted, and give me options that match the current build.
Subskills
These are the hosts I look at when more customers would mean more traffic.
- On the workbench
Cloudflare
The edge of the stack: tunnels, Pages, and Workers, and how a preview branch and a deploy Action ship the app.
- On the workbench
Fly.io
The app host when you do not want AWS. The setup that matters lives in a Dockerfile and fly.toml in the repo.
- On the workbench
Render
When the user wants the Render setup reviewed, including how it ships.
Five things this rule looks for
- More customers would mean more traffic, and you do not know what breaks first.
- You cannot say how the app is hosted, or where it runs.
- The current host fits today, and you have no next option when the business grows.
- A busy hour would stack the work in one place, with nowhere for it to go.
- The options in front of you do not match the stage the build is actually at.