The side-project double tax nobody mentions

A hobby "free" tier that forbids commercial use, on top of a time tax you can't invoice — the real cost of a side project isn't runtime, it's ownership.

Nobody reads the Hobby Terms until the project stops being a hobby. Two clauses buried in the fine print do more to shape the fate of a side project than any performance benchmark does, and neither shows up in your invoice.

The First Tax: You Can't Ship It

Most "free" and Hobby tiers of managed databases and platforms carry a no-commercial-use clause. The pricing page shows a generous resource envelope — that's the hook. What it doesn't show is that the moment you want to charge a customer, every one of those pricing assumptions breaks:

• The no-commercial clause makes the whole stack unlicensed for the thing that pays.
• You now have two pricing puzzles: the runtime bill you can see, and the licensing/compliance bill you can only read about in a PDF.
• The math that made the project viable ("free on Hobby") is the exact math that makes the upgrade painful ("$X/mo starting at usage_threshold").

A side project on a no-commercial tier isn't a startup waiting to happen. It's a demo that legally has to stay one.

The Second Tax: The Metadata You Didn't Budget

The second cost is invisible because it lives in the allocated, not the used. A fresh, completely empty Postgres instance still reserves memory and disk before a single row exists:

-- pg_memory_check: what an "empty" instance actually holds onto
SELECT pg_size_pretty(pg_database_size(current_database())) AS db_size;

SELECT name, setting, unit
  FROM pg_settings
 WHERE name IN ('shared_buffers', 'work_mem', 'effective_cache_size');

A barely-used instance on a 35-50MB-per-instance baseline feels "free" — until you multiply it by one database per microservice, per environment, per teammate. The platform bills you for the reservation, not the emptiness. Empty doesn't mean cheap; it means a bill with nothing to show for it.

This is where AI-coding-tool side projects get hit hardest: a demo app scaffolded into one empty database per feature, each one reserving its slice. The "free" weather-coded demo quietly becomes a monthly line item nobody planned for, in a tech that moved too fast to have a budgeting wiki.

The Fix

Before you build, answer two questions — and make the answers a repo file, not a memory:

1. Can you legally sell it? Read the Hobby Terms of every service you depend on before the first commit. If any of them forbids commercial use, your deployment model is already wrong for the goal. Pick the tier under which "this actually grows" is licensed — or acknowledge you're building a portfolio piece, and price accordingly.
2. How many starters actually run? Count every empty instance before you create it. One database per piece of real content shared across services beats five empty silos. Budget the allocation, not the usage — the invoice reads the former even when you only have the latter.

TACTICAL DEBRIEF

Side projects are taxed twice: once by licensing you discover too late, once by allocations you never see. Both are pricing decisions dressed up as scaling problems. Budget the second bill before you ship, not after the invoice lands — and sign nothing that says "hobby" if you mean "business."

---

Sources

• The invisible cost of managed Postgres — a practitioner breakdown of baseline memory/disk reservations on cloud instances: jcalloway.dev
• Postgres pg_settings reference — authoritative units for shared_buffers, work_mem, effective_cache_size (defaults per postgresql.conf): postgresql.org/docs/current/runtime-config-resource
• Side-project pricing after the honeymoon — why free tiers sit on legal and allocation debt, dev.to sociology thread (2026-05): dev.to

We document the real failure modes of the serverless pipeline — bills, caches, and agent workflows — on our YouTube channel. Link in bio.