Aftermath
The profitability problem, stated plainly
These projects are side projects that must pay for themselves. Each one lives under one rule: it must earn at least 25 CAD per hour of my time, after its infrastructure, measured over 90 days:
(net revenue over 90 days − 3 × monthly infrastructure) ÷ (3 × monthly hours) ≥ 25 CAD/hWith about 24 CAD a month of infrastructure and 3 hours a month of upkeep (both estimates):
- at 100 USD a month net revenue, the site earns about 37.7 CAD/h — it passes;
- at 50 USD a month, it earns about 14.9 CAD/h — it fails.
That is a thin margin, and it is the honest starting point. Three things make it hard:
- Revenue starts at zero. The old app had 4 users and no revenue. Any fixed cost is a loss until the first sale.
- Free plans have a hidden price. Hobby cost 0 USD, but it forbade selling, it stopped deploys on busy days, and one app could starve the rest. The cost showed up as lost hours, and hours are the most expensive line in the formula.
- Hours beat dollars. Saving 20 USD a month is worth nothing if it costs 3 hours of upkeep. At our billable rate of 85 USD an hour, one lost afternoon erases a year of hosting savings.
Why these decisions, for what comes next
- Static pages on a free static host. A page that is rendered once at build time costs nothing to serve at zero traffic and stays fast at any traffic. The new flowingkhaos site works this way.
- Always-on servers in a container, for a fixed floor. The CMS and the site’s small API run on Railway. The floor is known in advance, and one busy service cannot take a shared free pool away from the others.
- Data where it is already free and safe. Neon Free holds everything, with branching and point-in-time restore we would otherwise build ourselves.
- No Kubernetes, ever, at this size. The step above one server is a second server.
- Paid plans only when revenue asks for them. Vercel Pro is 20 USD per seat per month. It buys the right to sell, not a better architecture.
What would reverse this
Each decision has a number that overturns it. We read these monthly:
| Decision | Reversed when |
|---|---|
| CMS on Railway | its usage exceeds 25 USD a month for two months → measure again, per project |
| Data on Neon Free | storage passes 0.5 GB, compute passes 100 CU-hours a month, or egress passes 5 GB — any of which suspends every app at once — and Neon’s paid plan costs more than a Railway Postgres |
| Data on Neon at all | the box is sold as a product: a product cannot depend on someone else’s database account |
| Accounts on the flowingkhaos site | net revenue under 100 USD a month at the 90-day review → the accounts layer is switched off, and the site stays static and free |
Where it stands
Monitoring. The CMS has served from Railway since 2026-09-16. Neon compute read 36 of 100 CU-hours for the month on that day, with four days of an always-on CMS already inside it, and the database still sleeps between requests (measured). The first Railway invoice is the number that confirms or refutes the saving. When it arrives, it goes in the timeline.