Every piece of advice for solo founders says the same thing: build a monolith. One repo, one deploy, one database, ship fast, refactor later. It's good advice. I ignored it, and this entry is about why — and about the cloud-economics shift that made ignoring it rational instead of reckless.
The cost philosophy comes first
PlayersEngine is bootstrapped. There's no funding runway burning down, which means the infrastructure bill is existential in a way latency is not. So the founding principle of the whole architecture is blunt: design for a million users, pay for the users you actually have. Every technology choice below follows from that single constraint.
That principle has a name in cloud terms: scale-to-zero. A service that nobody is calling should cost nothing. A database with no traffic should cost nothing. Idle capacity is the silent killer of bootstrapped projects — you provision for the launch spike, the spike ends, and you keep paying rent on empty servers.
Why Cloud Run
Google Cloud Run is the closest thing I've found to that ideal: you hand it a container, it runs as many copies as traffic demands — including zero. At 3 a.m. when the beta is asleep, my compute bill is asleep too. When something gets busy, it scales horizontally without me touching anything. For a one-person team, "without me touching anything" is not a convenience, it's the difference between sleeping and not.
The honest tradeoff is cold starts: the first request after an idle period pays a startup penalty. For a chat-speed trading system that would be disqualifying. For a social platform in beta, an occasional slow first request is a price I happily pay, and there are well-known mitigations when it starts to matter.
Why microservices, even alone
Here's the part that sounds wrong. The standard argument against microservices is operational overhead — and on traditional infra it's correct, because ten services means ten things to provision and babysit. But scale-to-zero changes the math: ten small services that each sleep when idle cost roughly what one sleeping monolith costs, which is to say roughly nothing. The overhead argument loses most of its teeth.
What I get in exchange:
- Blast radius. A bad deploy breaks one capability, not the platform. As the only engineer, I can't afford whole-system outages caused by a typo in a corner feature.
- Independent deploys. Small services ship in minutes, dozens of times a week, without coordinating anything.
- Forced boundaries. A monolith lets you smear logic everywhere because nothing stops you. Service boundaries are a discipline I outsource to the architecture — useful when the reviewer and the author are the same tired person.
Two databases, because data has shapes
Content and relationships are different shapes of data, and forcing them into one store hurts eventually. Posts, profiles, settings — self-contained documents, read far more than written. They live in Firestore, a document database that bills per operation, needs zero administration, and costs nothing at rest. Same philosophy as the compute layer.
Social relationships are the opposite shape: the value isn't in the records, it's in the connections between them. Ask a relational database for friends-of-friends-who-follow-the-same-things and you're staring at self-JOINs that get uglier and slower with each hop. A graph database stores the connections natively, so traversal queries that would melt SQL stay simple and fast. So: documents for content, a graph for the social fabric, each store doing the one thing it's best at.
Yes, two stores means keeping them consistent — that's real engineering tax, and I pay it deliberately. Anything that doesn't need to happen during a user's request (notifications, syncing, cleanup) goes onto a message queue and gets handled by a background worker, which keeps the user-facing path fast and the side-effects retryable.
The front door
Everything sits behind a managed API gateway: one place that checks authentication and routes to the right service, so individual services never reinvent security. TypeScript end to end, one monorepo so a single grep finds everything, and CI that builds and deploys each service when it changes. That tooling is what actually makes ten services manageable by one person — the services are small; the system around them does the remembering.
Would I recommend it?
Only with the whole package. Microservices without scale-to-zero billing and without ruthless automation would bury a solo developer. With them, I get big-team architecture on a hobby-project bill — my monthly infrastructure cost during the closed beta is less than a night out. The monolith advice isn't wrong; it's just priced for a cloud that's increasingly not the one we're renting.