HomeWritingPlatform For An Audience Of One

The Platform You Build for an Audience of One

Published Jul 18, 2026
Updated Jul 18, 2026
2 minutes read

At a company, "platform" means paved roads: CI, deploy, secrets, observability, shared libraries. As a solo builder, you are still the platform team — just without the headcount. The failure mode is either no pavement (every feature reinvents deploy) or overbuilt pavement (you spend a month on a developer portal nobody else will use).

The trick is sizing the platform to an audience of one without pretending you will stay that way forever.

Automate the weekly tax

I only invest in platform when the pain is recurring and measurable. Good candidates:

  • Release ritual — build, migrate, smoke check, announce
  • Secret and env drift — the same three vars copy-pasted wrong again
  • Incident leftovers — "check Vercel logs" should be one command, not a scavenger hunt
  • Content pipeline — timestamps, lint, sitemap for this site itself

If I have done the same manual sequence three times in two weeks, it becomes a script or a GitHub Action. Not a framework.

Borrow, don't invent

PeakofEloquence.org scaled past 490K users on boring, proven pieces. The solo version of that lesson: prefer hosted primitives over custom control planes.

  • Managed auth over your own session store — until auth is the product
  • One observability vendor over a home-grown metrics stack
  • Edge + static where you can; stateful services only where state is the point

Platform pride is expensive. Shipping a product users touch is the whole job.

Interfaces that survive growth

Even for an audience of one, name things like a future teammate might join:

  • A single make ship (or bun run release) that is safe to run tired
  • Config in one place, not scattered .env folklore
  • Runbooks as markdown next to the code that fails

When AutomateHub grows past me, I want the paved road to already exist — thin, documented, and slightly embarrassing in its simplicity.

What I refuse to platform early

  • Multi-tenant admin UIs before there is a second tenant
  • Internal design systems before there are three real screens sharing components
  • Custom queue abstractions over the vendor's queue
  • "AI ops" layers that generate tickets I still have to triage

Complexity compounds. Solo platform work should delete steps, not add ceremony.

The test

Ask: if I disappeared for two weeks, could a sharp engineer restore production from the repo and the runbooks alone?

If yes, you have a platform — even if the audience is still just you.