$0 until it isn't: how I talked myself out of a server

TL;DR: Building the backend for my Solana Seeker mobile app, I kept reaching for a “real” server — a VPS, a proper always-on box. Every time, I talked myself back out of it, because when I actually interrogated why I wanted one, the honest answer was usually “because that’s what backends have,” not “because this needs it.” The app now runs its backend for roughly the cost of a coffee per month, on free and near-free tiers, and only spends money where money genuinely buys something. This is the story of right-sizing infrastructure by repeatedly asking “do I actually need this, or does it just feel professional?”

---

There’s a moment in every project where you feel like you should stand up a server. A real one. An always-on Linux box with your name on it that Does The Backend Things. It feels like a rite of passage. It feels legitimate.

I nearly did it three or four times. I’m glad I didn’t, and the reasoning is more interesting than the outcome.

The question that killed the VPS

My app needed a backend for a few genuine reasons: signing uploads to permanent storage with a key that can’t live on the phone, some scheduled treasury bookkeeping, and a bit of shared state. Classic “you need a server” territory.

So I started speccing a VPS. And then I made myself answer one question honestly, per piece of work: does this specific thing require a machine that is always on and that I manage — or does it just need to run when something happens?

Turns out most of it just needs to run when something happens. A user mints; some code signs an upload. That’s not an always-on workload. That’s an on-demand one. And on-demand code doesn’t need a server sitting there idling (and billing) 24/7 — it needs a serverless function that wakes up, does the thing, and goes back to sleep.

The stuff that did seem to need always-on — scheduled bookkeeping, a keeper that tops things up on a threshold — I looked at harder and realised: (a) at my volume, those events barely happen, and (b) the parts of the platform I was already on could run scheduled jobs without me babysitting a box. A cron trigger on a serverless platform is the “always-on machine” for a job that runs every few hours. There’s no box. The box was imaginary. I’d been about to rent an imaginary box to solve a problem I could describe but hadn’t confirmed I had.

I did the same interrogation with a couple of paid hosting options. Same result: each time, the honest reason I wanted them was “this is how serious apps are built,” not “this specific constraint forces it.”

The stack I actually landed on

Everything ended up on one platform’s developer tier, mostly free:

• Serverless functions for the on-demand backend — signing, generating things, reading and writing state. Fires only when a user acts. Idle cost: zero.
• A serverless SQL database for the shared state — roll records, checkpoints, bookkeeping. Free tier, and at my scale it stays free for a long time.
• Scheduled triggers for the periodic jobs — the bookkeeping and monitoring that would have “justified” the VPS. No always-on host. They just fire on a clock.
• Permanent storage for the actual user content, paid per-upload, which is a real cost of goods rather than a subscription — more on that below.

The whole thing runs at roughly the price of a coffee a month, and most of that is one deliberate paid choice, not a pile of subscriptions.

Where I did spend money — and why that’s the interesting part

Here’s the nuance that makes “use the free tier” more than a cheapskate slogan: the goal was never “spend nothing.” The goal was spend only where money buys something real.

Two places forced honest spending, and they’re instructive:

A durable job queue. The trickiest part of my mint flow is a background job that has to survive a crash and retry cleanly — exactly the shape a managed queue is built for. That queue lives behind a paid tier. Five dollars a month. I resisted it at first (reflex), then asked the real question: is the alternative — hand-rolling crash-safe retry logic myself — worth not spending five dollars? No. The five dollars buys me a solved problem I’d otherwise have to build and maintain. That’s money buying something. Approved.

Permanent storage credits. Storing user content permanently is a genuine per-item cost — permanence isn’t free, because someone has to be paid to store a thing forever. And the credits I buy to do it are non-refundable and expire. That changes the discipline entirely: I fund small, top up as needed, and never stockpile. It’s the one place where “just throw money at it to be safe” is actively the wrong move, because over-funding is money you can’t get back. So the cheapest correct behaviour is also the most careful one.

The pattern across both: I didn’t refuse to spend. I refused to spend reflexively. Every dollar had to answer for itself.

The philosophy, stated plainly

The rule I ended up with: run at $0 until real volume justifies real cost, and build so that flipping to the bigger, more expensive setup is a config change, not a rewrite.

That second half matters as much as the first. Cheap-now is only smart if it doesn’t paint you into a corner. So the whole thing is built behind seams — the storage provider, the funding logic, the treasury handling are all interfaces. The $0 version and the fully-automated, real-money version differ in which implementation is plugged in, not in the shape of the app. When volume arrives, I turn dials. I don’t rebuild.

It also means I’m not paying today for capacity I’ll need at a scale I haven’t reached. The most expensive infrastructure decision isn’t the monthly bill — it’s paying for “what if we go huge” while you’re still proving anyone wants the thing at all.

Lesson learnt

Interrogate every piece of infrastructure with “do I actually need this, or does it just feel professional?” — and be honest about the answer.

A VPS felt professional. It wasn’t needed. A pile of paid services felt serious. Most weren’t earning their keep. The genuinely-needed spends (the queue, the storage) revealed themselves precisely because I made everything else prove it first — the signal stood out once I’d cleared the reflexive noise.

There’s a version of “building a real product” that’s mostly cosplay: provisioning the boxes and dashboards and subscriptions that look like seriousness. And there’s the actual version, which is quieter and cheaper and occasionally feels like you’re not doing enough — where you spend money only when money buys something, and where “it runs for the cost of a coffee” is a feature, not an embarrassment.

Right-sizing isn’t about being cheap. It’s about matching what you spend to what you actually need, and having the discipline to tell the difference between the two — especially when the expensive option is the one that would make you feel more legitimate. Legitimacy isn’t a line item. Shipping is.