Cost as a Design Constraint: FinOps on a £0 Budget

When people hear "£0 budget," they usually think "hobby project." But the Cycle Kirklees platform runs production workloads for real users on a self-hosted stack that costs nothing per month to operate. That constraint wasn't a limitation. It was the best design pressure I've ever worked under.

The constraint is the architecture

Most FinOps conversations start with a cloud bill and work backwards: "How do we reduce this?" The £0 budget inverts the question. You start with nothing and ask: "What can we build that costs nothing to run?"

That sounds restrictive, but it forces clarity about what actually matters. When you can't spin up a managed service to solve a problem, you have to understand the problem. When you can't pay for a monitoring tier, you have to know exactly what you need to monitor and why. The constraint strips away the luxury of over-provisioning.

Where the £0 maps to cloud cost patterns

The pattern is the same in every row: the cost governance decision was made at architecture time, not at invoice time. That's what good FinOps looks like: not chasing savings after the bill arrives, but designing the system so the bill never arrives.

We also used Azure to back up critical membership data for fractions of a penny per day. We'd be surprised if we get billed before 2028—unless the platform grows beyond my wildest imagination.

The honest accounting is that £0 isn't free. I pay in time: mine, on evenings and weekends. The Proxmox host consumes electricity. The DNS records cost nothing because Cloudflare's free tier covers them, but that's a deliberate choice, not a gift.

The FinOps framing matters here because platform engineering teams face the same trade-off at scale. "Should we run this ourselves or pay someone to run it?" is the fundamental platform cost question. My £0 budget forced me to answer it honestly for every single component, and the answer was never "self-host because it's cheaper." It was "self-host because the cost of the managed alternative doesn't justify the cognitive load it removes, given the volume we're running."

That's the same calculation a platform team makes when deciding whether to offer a managed database as a golden path or let teams self-serve. The difference is that most teams have enough budget to avoid the question. I didn't, so I had to answer it.

What I'd do differently with budget

If I had a cloud budget for this platform, here's where I'd spend it:

1. AKS for the Kubernetes workloads. The operational overhead of patching k3s nodes and managing etcd backups is real. AKS removes that. The cost is justified at any scale where downtime costs more than the node fee.
2. Azure Monitor instead of self-hosted Prometheus. The self-hosted stack works, but Azure Monitor's correlation across services and infrastructure is genuinely better for multi-workload platforms. The ingestion pricing stings at high volume, but the operational simplicity wins.
3. Managed CDN with WAF. Cloudflare's free tier is excellent, but the WAF rules and bot management in the Pro tier would have saved me hours of hand-tuning rate limits and access controls.

The point isn't that self-hosting is always right. It's that the £0 constraint taught me exactly where the break-even points are, and that's the most useful thing a platform engineer can know when advising on cloud spend.

The takeaway for platform teams

FinOps isn't about cutting costs. It's about making cost-visible decisions at architecture time. When you build with a £0 budget, every decision is cost-visible by definition: there is no hidden spend to discover later. That discipline transfers directly to cloud platform work: if you can design a production platform that costs nothing, you can design one that costs the right amount.

The constraint was the best teacher. Not because it forced me to be cheap, but because it forced me to be deliberate.

Where's the break-even point you've found between self-hosting and managed services? Share it in the comments.