Every SaaS eventually becomes two products: the thing customers buy, and the infrastructure required to keep it alive. The first gets the roadmap, the launch posts, the attention. The second grows quietly in the background — and consumes far more of the team’s time than anyone planned for.
Most teams assemble that second product one decision at a time. DNS from one company. Hosting somewhere else. Storage from a third. Functions from a fourth. A CDN bolted on afterwards, caching added six months later, monitoring from another vendor again. Nothing about this is wrong — it’s how most stacks come to exist. But every boundary between providers introduces latency, complexity, and one more thing somebody has to understand.
Every additional provider is another dashboard, another billing account, another API, another outage page, another authentication model, another failure mode.
We wanted fewer moving parts. So when we built the platform behind Plus±, we made an unfashionable decision: almost everything runs on Cloudflare.
This is the reasoning. Though it’s worth saying upfront: the decision was never really about Cloudflare. It was about operational simplicity. Cloudflare is simply where that principle led us.
We optimise for simplicity
Every SaaS becomes two products — and so does every architectural decision. Each one creates a capability, and an operational burden that arrives with it. Most evaluations price the first and quietly inherit the second.
Infrastructure decisions are usually made independently, each one locally sensible. We asked a different question first:
How few providers can we responsibly use?
Not because fewer is fashionable — because fewer systems are easier to understand. Simpler systems fail less, cost less to operate, are easier to document, and are far easier to bring new people into. When your entire platform fits in one person’s head, a small team can move like a much larger one.
We didn’t choose Cloudflare because it offered the most features. We chose it because it removes infrastructure decisions — and every decision it removes is attention returned to the product.
Why Cloudflare became the centre
Like most companies, we were already using Cloudflare before we committed to it. It handled our DNS, domains, SSL, CDN, caching, and security — the layer every request passes through before it reaches anything we’ve built.
At some point the obvious question asks itself: if we already trust Cloudflare with every byte of traffic, why move the application somewhere else?
Traffic was the centre of gravity. We let the rest of the platform settle around it.
What runs where — and why
Here’s the whole architecture, conceptually:
The list matters less than the reasoning, so briefly, decision by decision:
Domains and DNS live on Cloudflare. One control plane, one SSL model, one dashboard — unremarkable, which is the point.
Static sites — the marketing site, documentation, this journal — are Astro on Cloudflare Pages: served near users globally, deployed in seconds.
The web application is Svelte, also on Pages. Same deployment model, same edge network, same tooling — no second hosting philosophy to learn.
APIs are Hono on Cloudflare Workers — tiny, fast, edge-native. No servers to manage, no containers to orchestrate, nothing sitting idle overnight — which means the platform scales with the work rather than waiting for it.
Storage is R2 — journal media, assets, deliverable files — integrated with Workers and Pages, and with no egress surprises waiting in a future invoice.
The database is the honest exception: Neon, not Cloudflare. Cloudflare isn’t a database company, and pretending otherwise would trade real capability for tidiness. Neon gives us serverless Postgres with branching and a genuinely good developer experience.
Hyperdrive is what makes the exception work. Workers run globally; the database is, by nature, more central; Hyperdrive shortens the distance between them.
Which is the actual principle at work here — not one vendor at any cost, but tools chosen because they complement each other.
The invisible benefit
The biggest benefit of this architecture isn’t speed. It’s cognitive load.
Instead of learning five deployment systems, five CLIs, five dashboards, and five permission models, the team learns one. Every project — a marketing page, an API, the client dashboard — deploys the same way, logs the same way, and fails in familiar ways.
There’s a bigger idea underneath this, and it took us a while to name it:
Architecture is the user experience your team has every day.
Products have UX. Engineering teams have UX too — theirs is the architecture. Every deployment model, logging system, dashboard and permission scheme is an interface somebody works inside daily. Seen that way, infrastructure choices stop being procurement and become design decisions — with users, friction, and consequences, like any other design.
So we approached the platform the way we’d approach a product: designed for the people who have to live in it.
Architecture compounds
Small architectural decisions don’t stay small.
One deployment model becomes every deployment. One permission model becomes every new team member’s first day. One logging system becomes every debugging session. One platform becomes every product you build next year.
Architecture compounds in exactly the same way features do — we wrote recently that every feature has a maintenance cost, an invoice that arrives every sprint. Architecture sends the same invoice with the opposite sign. A feature bills you forever; a sound architectural decision pays you forever. You make it once, and you collect on it in every project that follows.
That’s also the honest answer to why any of this matters. Plus± is a deliberately small team, and this is what makes that viable: the less time we spend operating infrastructure, the more time we spend improving products. A coherent platform is how a few people behave like many.
Development mirrors production
A quieter advantage, and an underrated one: local development resembles what actually ships.
Workers, Pages, Hono, Svelte — the architecture a developer runs locally is structurally the same as the one serving customers. There’s no moment where code that worked all week meets a production environment it has never seen. That closeness reduces deployment bugs, environment drift, and the category of surprise that only appears after release — usually on a Friday.
The edge changes how you build
This one surprised us slightly.
When compute already sits near your users, you naturally build differently. Services get smaller. Requests get lighter. You stop thinking in terms of servers to fill and start thinking in terms of requests to answer. Nobody mandated this — the platform’s shape quietly encouraged it.
It also compounds with something we’ve argued before: speed creates confidence. Responsiveness isn’t only a code-level property; it’s partly geography. Removing unnecessary distance between users and application logic is the cheapest performance work you’ll ever do, because it’s done once, by the architecture, for everything built on top of it.
What we didn’t optimise for
Worth being explicit, because this article could easily read as evangelism. We did not choose Cloudflare because it’s fashionable, because everything is free, because it’s objectively the best, or out of vendor loyalty.
We optimised for clarity, consistency, operational simplicity, and long-term maintainability — the things that matter most to a deliberately small team intending to own its platform for years. A different team, with different constraints, could weigh the same factors and land somewhere else entirely. That wouldn’t make either of us wrong.
The trade-offs, stated plainly
No architecture is free, and this one has real costs:
- Vendor concentration. More of our platform depends on one company than most teams would default to. If Cloudflare has a bad day, so do we.
- Lock-in. Workers, R2 and Pages have their own models. Leaving would be work — meaningful work.
- A different mental model. Workers aren’t traditional servers. Some software expects VMs, long-lived processes, or a filesystem, and doesn’t belong here.
- Not every workload fits. We know where the edges of the edge are, and we design within them.
These are deliberate trade-offs, not hidden downsides. We accepted concentration in exchange for coherence — knowingly, and in writing, which is roughly what this article is.
Architecture should disappear
Customers never buy infrastructure. They buy software. The infrastructure exists to keep a promise the product made — and the less it demands from the team along the way, the better it’s doing its job.
Good infrastructure is like good design. When it works well, you stop noticing it.
If a team spends its days discussing hosting providers, the architecture is demanding attention that belonged to the product. Good architecture does the opposite: it gets quietly out of the way and stays there.
That, in the end, is why we chose Cloudflare. Not a stack that impresses engineers — a stack that lets a small team spend its time building products rather than managing the platform beneath them.
Plus± is a product design and development studio. We build the way this article describes—deliberately, with fewer moving parts, on foundations designed to be owned for years. Explore our approach, or get in touch if you’d like to build the same way.