Cloud architecture & advisory
Cloud architecture and advisory is the work of deciding how your software is built, hosted and run before — or after — a line of application code is written: where it lives, how it scales, what it costs to operate, and where the risks are. We're Klura, an independent fullstack studio in Stockholm, and this is the part of our work where you hire a senior pair of hands rather than a finished feature. We design and build serverless systems on the edge (Cloudflare Workers + Neon Postgres), review an existing architecture and tell you plainly what's solid and what isn't, or take a team's stalled infrastructure decision off their plate. This very site runs on exactly that stack — TanStack Start on Cloudflare Workers — so when we recommend it, we're pointing at something live, not a slide. This page covers what cloud architecture and advisory with Klura involves, how we work, the stack and the honest tradeoffs, and what it costs.
What this is — and when you actually need it
Cloud architecture is the set of decisions underneath an application: the hosting model (servers, containers, or serverless), the database, how requests reach users, how secrets and config are handled, and how the whole thing is deployed and observed. Advisory is the same expertise applied to a decision rather than a deliverable — a second senior opinion when a team is choosing a stack, a review of a system that's grown organically, or a focused engagement to plan a migration. Both are about getting the foundation right so the product on top of it stays cheap to change.
The honest part first: most small products do not need a cloud architect. If you're shipping a straightforward app or site, the right architecture is usually the boring, managed one — and a good builder will set it up correctly as part of the build without a separate advisory phase. You need this work when the stakes or the complexity are real:
- You're about to commit to a stack or a cloud provider and a wrong call is expensive to undo later.
- An existing system is slow, fragile, or surprisingly costly to run, and nobody can quite say why.
- You're outgrowing a no-code or template setup and need to plan the move to something you own.
- Your team is strong but missing one specific area — edge, serverless, type-safe infrastructure — and needs a senior to design it or sanity-check the plan.
- Hosting or database bills are climbing faster than usage and you want them brought back to earth.
If none of those describe you, we'll say so. We'd rather tell you the architecture you have is fine than invent a problem to solve.
How we work: review → build / migrate → handover
Advisory and architecture work is open-ended by nature, so we structure it into three phases with a clear output at the end of each. You can stop after any one of them — many engagements are just the first.
- 1. Architecture review. We start by reading what exists — code, infrastructure config, the database, the bills — and talking through where it hurts and where you're heading. The output is a written assessment: what's solid, what's a real risk, what's a false alarm, and a prioritised list of what to change, with rough effort and cost against each. This phase stands alone; plenty of teams just want a clear-eyed second opinion they can act on themselves.
- 2. Build or migrate. If you want it done rather than documented, we design the target architecture and build it — a new serverless setup, a migration off a stack you've outgrown, an edge layer in front of a slow app, type-safe infrastructure-as-code so deploys stop being scary. We move in reviewable steps against the priority list, so the system keeps working while it changes rather than stopping for a big-bang rewrite.
- 3. Handover. The work is only finished when your team can run it without us. We hand over documented infrastructure-as-code, a deployment that anyone can trigger, the reasoning behind each decision, and a walkthrough. No lock-in to Klura: the whole point is that you own and understand what you're running.
What you get
The exact scope depends on which phases you take, but a cloud architecture and advisory engagement with Klura typically includes some combination of:
- A written architecture assessment — honest strengths, real risks, and a prioritised, costed list of changes.
- A target design — the hosting model, database, edge and deployment approach chosen for your actual needs and budget, not the trendiest option.
- Implementation — the new architecture or migration built in reviewable steps, with the system staying live throughout.
- Infrastructure-as-code — your setup defined in code (e.g. Terraform), version-controlled and reproducible, so environments are predictable and deploys aren't a leap of faith.
- Cost and performance work — finding and removing the lines on your bill (or your latency budget) that don't earn their place.
- A senior second opinion — on a stack choice, a vendor, a scaling plan, or a design your own team has drafted.
- Documentation and handover — so your team owns the result and isn't tied to us.
The stack — and why (with the tradeoffs)
Our default architecture is serverless on the edge: application code on Cloudflare Workers, data in Neon Postgres, TypeScript end to end, and the whole thing defined in infrastructure-as-code. It's the same stack we build web platforms and apps on, and the same one this site runs on. Here's what each piece buys you — and what it costs you, because every choice is a tradeoff.
| Choice | Why we reach for it | The honest tradeoff |
|---|---|---|
| Cloudflare Workers (edge serverless) | Code runs close to users in hundreds of locations, scales to zero when idle and up under load with no servers to patch, and is cheap to run at small scale. | It's a constrained runtime, not a full Node server — some libraries and long-running jobs don't fit, and you architect around that rather than ignoring it. |
| Neon Postgres (serverless database) | Real, standard Postgres that scales and branches like serverless, works from the edge, and costs little when traffic is low. | It's managed and usage-priced — great for variable load, but a fixed always-on box can be cheaper at steady high volume, and you should know which case you're in. |
| TypeScript end to end | One language and one set of types from database to UI catches whole classes of bugs at compile time instead of in production. | It asks more of the build setup and the team up front; the payoff is fewer 3am surprises, not less typing. |
| Infrastructure-as-code (Terraform) | Your environment is reproducible, reviewable and version-controlled — no undocumented clicks in a dashboard that nobody can reproduce. | There's a real learning and setup cost; for a throwaway prototype it can be overkill, and we'll tell you when it is. |
We're not religious about it. Edge serverless is an excellent default for most modern products, but it isn't the answer to everything — a heavy data-processing job or a system tied to a specific cloud's services may belong elsewhere, and we'll say so. The reason we lead with this stack is that we run it in production ourselves: klura.app is TanStack Start on Cloudflare Workers, deployed from infrastructure-as-code via GitHub Actions. When we recommend an architecture, you can look at one we operate and ask how it actually behaves.
What it costs
Advisory and architecture work is priced by time, not by deliverable, because the value is senior judgement rather than a fixed artifact. As a guide, senior independent rates in the Swedish market in 2026 run roughly 800–1 200 kr/h. We work two ways:
| Engagement | Shape | Indicative cost (SEK, 2026) |
|---|---|---|
| Architecture review | A focused read of your system with a written, prioritised assessment | From ~15 000 kr, scoped to the size of the system |
| Advisory by the day | Senior architecture time for reviews, stack decisions, planning or pairing | ~6 500–9 500 kr / day, or by the hour at the senior rate |
| Build or migration | Hands-on implementation, scoped after the review | Fixed proposal once scope is clear, or time-and-materials |
Because Klura is a senior, independent studio — no account manager, no sales layer, no junior time billed as senior, no agency overhead baked into the rate — the figure above is mostly the actual work. We don't publish a fixed price list, because an honest number depends on your system and a made-up one helps nobody. For the numbers behind a full app build, see our cost guide; for cloud and advisory specifically, we'll give you a straight range on a first call and a fixed proposal once the scope is clear.
FAQ
What is the difference between cloud architecture and just building the app?
Cloud architecture is the decisions underneath the app — hosting, database, scaling, deployment, cost — while building the app is the application code on top. On a normal build, Klura handles both: a good builder sets up a sound architecture as part of shipping the product. You'd hire architecture or advisory on its own when the decision is high-stakes (a stack choice that's costly to reverse), when an existing system needs assessing, or when your own team is building and just wants a senior to design or check the foundation.
Do I actually need a cloud architect?
Often, no — and Klura will tell you so. Most small products are best served by a boring, managed, serverless setup that's configured correctly during the build, with no separate advisory phase. You need dedicated architecture or advisory work when the complexity or the stakes are real: a stack you're about to commit to, a system that's slow or expensive for reasons nobody can pin down, a migration off something you've outgrown, or a gap in one specific area like edge or serverless. If your current architecture is fine, we'd rather say that than invent a problem.
What does 'serverless on the edge' mean, and why does Klura use it?
Edge serverless means your code runs in many locations close to users (on Cloudflare Workers) and scales automatically with no servers to manage, paired with a serverless database (Neon Postgres). For most modern products it's fast, cheap at small scale, and low-maintenance. Klura uses it because it's a strong default and because we run it in production: klura.app itself is TanStack Start on Cloudflare Workers. The tradeoff is a more constrained runtime — not everything fits, and we'll tell you when a different approach is the right call.
Can Klura just review our architecture without building anything?
Yes — that's the architecture review on its own, and it's a common engagement. We read your code, infrastructure, database and bills, then deliver a written, prioritised assessment of what's solid, what's a genuine risk, and what to change, with rough effort and cost against each item. Plenty of teams take that and act on it themselves. If you later want it implemented, we can do that too, but there's no obligation to continue.
Will we be locked in to Klura after the work is done?
No, by design. The handover phase exists precisely so your team can run the system without us: documented infrastructure-as-code, a deployment anyone can trigger, and the reasoning behind each decision. The whole point of doing this properly is that you own and understand what you're running — Klura being a registered Swedish AB with a named, accountable owner, not a dependency you can't replace.
Wondering whether your cloud setup is right — or which way to jump on a stack decision? Tell us roughly what you're running or planning, and we'll give you a straight read. Email hej@klura.app.