The bill is not the cost

Cost optimization at small scale is mostly about something other than the bill. Starting from the bill produces weeks of work to save the price of a sandwich.

What this system costs to run

A virtual private server. It runs the application container, its accessories (Postgres and the challenge grader) and kamal-proxy.

A domain name, and a container registry, which is free for this usage on GitHub.

The rest is small. The fonts come from fonts.bunny.net and some JavaScript from cdn.jsdelivr.net, both free at this volume. Storage is the Disk service on the same machine, so there's no object storage bill. Cloudflare sits in front of the site, and backups run outside the repository.

So the infrastructure bill is small and fixed: a server, a domain and a few services priced by the month or free.

What it costs to operate

Every hour spent on it.

At any realistic value of an engineer's time, a single afternoon costs more than a month of that server, and a week of work costs more than a year of it.

That's the actual ratio, and it inverts the usual advice. For a system this size, the expensive resource is attention, and the cheap one is hardware.

flowchart TB
  C["total cost"] --> I["infrastructure: one server, one domain"]
  C --> T["operator time: every hour spent on it"]
  I --> S["small, fixed, predictable"]
  T --> L["large, and the thing actually being spent"]
  L --> D["so optimise for time, and buy your way out of work"]

What this changes

Buying a larger server to avoid a week of optimization work is correct arithmetic. It feels wrong to engineers, because the bill is visible and the time isn't.

The roadmap optimizations earlier in this project took it from about 310 milliseconds to about 72 and cost real hours. They were worth doing because they taught something and improved every user's experience. "It saved money" would have been false, though, since the server cost the same before and after.

Most performance work at this scale is bought with time and paid for in experience quality, not in money. Being clear about which currency you're spending keeps the two from being confused.

When the bill starts to matter

When a component is billed by usage instead of by the month. A server costs the same whether it's idle or busy; object storage, egress bandwidth and per-request services don't.

This application's main costs aren't billed that way, which is why its bill is flat and boring. A flat, boring bill is itself a design outcome worth noticing.

Key takeaways

• The infrastructure here is a server, a domain and a few flat-priced or free services.
• At any realistic rate, an afternoon of work costs more than a month of that server.
• The expensive resource at this size is attention; the cheap one is hardware.
• Buying a larger server to avoid a week of work is correct arithmetic that feels wrong.
• Bills start to matter when components are billed by usage instead of by the month.