Every studio reaches a point where the tools that got you started stop being the tools that get you where you’re going. For us, that moment arrived with Webflow.
We loved Webflow, and in a lot of ways we still do — it’s a phenomenal way to move fast on marketing sites and get a client’s vision live without a six-week build. But as our clients’ ambitions grew, so did the demands we were placing on it. We started bolting on custom data layers here, mounting interactive components there, wiring up bits of JavaScript to make a visual design tool behave like an application. Each individual patch was fine. Taken together, they were a sign. We weren’t building websites anymore — we were building products, and we were building them on top of a tool that was never designed for that job.
So we went looking for a real foundation: a full-stack framework we could commit to as our default, one that could handle everything from a simple marketing page to a data-heavy client dashboard without switching tools halfway through. That search led us to SvelteKit, and a couple of years and dozens of projects later, it’s not an exaggeration to say it’s changed how we work.
The evaluation.
When we compared frameworks, we didn’t go in with a favourite. We looked at the major options the way we’d look at any tool we were about to build a business on: performance, developer experience, the size and readability of the resulting codebase, and how quickly a new team member could get productive in it.
Svelte kept winning on all four.
The core of it comes down to how Svelte works under the hood. Most JavaScript frameworks ship a runtime to the browser — a chunk of library code whose job is to compare your application’s state against the DOM and figure out what changed, every time something updates. That’s the “virtual DOM” model, and it works, but it’s overhead: code the browser has to download, parse, and run before your app even starts doing its job.
Svelte takes a different approach. It’s a compiler. It does that comparison work at build time, not in the browser, and outputs small, surgical JavaScript that updates exactly the parts of the DOM that need to change. There’s no framework runtime shipped to the client — just your code, distilled. The practical result is smaller bundles, faster first loads, and less work happening on every device your site touches, including the underpowered ones.
We felt that difference immediately, not as an abstract number but as a feeling: pages that snapped instead of settling.
Why SvelteKit specifically.
Svelte is the language. SvelteKit is what makes it a serious platform for client work. It’s the layer that gave us everything Webflow-plus-patches never quite could:
- File-based routing that maps cleanly onto how we think about a site’s structure, with no separate routing library to configure and maintain.
- Server-side rendering and static generation, chosen per-route, so a marketing page can be pre-rendered to the edge while a logged-in dashboard renders fresh on every request — in the same project, without contorting either use case to fit the other.
- Load functions and form actions that give us a clean, built-in way to move data between server and client, instead of the improvised glue code that pattern usually demands.
- A genuinely full-stack story. We can write API endpoints, handle authentication, and manage server logic in the same project as the front end, which means fewer moving parts, fewer repos, and fewer places for something to quietly break.
For us, that last point mattered more than any benchmark. Complexity is a cost every client eventually pays for, whether it’s in their invoice or in how long it takes us to safely make a change six months later. SvelteKit let us collapse a stack that used to be four or five tools into one coherent framework.
Pragmatic, not dogmatic.
We want to be upfront about something: we chose Svelte for the front end, but we didn’t marry ourselves to one way of doing everything. For backend services we reach for Hono when we want something fast and minimal, and every so often a project calls for Go — usually when raw performance or concurrency is the whole point. We pick tools for the job in front of us. It just happens that, for the front end, Svelte is the tool that keeps being the right answer.
We should also be honest about the trade-offs, because a framework choice without any downsides isn’t a real evaluation, it’s marketing copy. There’s a common assumption that Svelte’s ecosystem is small compared to React’s — the industry default, and for good reason, given its head start and adoption. In practice that gap is smaller than it looks. Svelte components aren’t a new language bolted onto JavaScript; they’re HTML, CSS, and the JS or TS you already know, extended with a small set of template syntax for things like conditionals and loops. Because of that, Svelte doesn’t need a Svelte-specific version of every package the way some frameworks do — it can use the vanilla JavaScript ecosystem directly. Svelte-native packages tend to be more reactive out of the box, but they’re an enhancement, not a requirement. The result is an ecosystem that’s larger, and more mature, than the “Svelte-only” package count would suggest.
Where the trade-off is real is around the wider talent pool: more developers currently know React, simply because it’s been the default for longer, and some clients — particularly larger organisations with an established stack — come to us already expecting it. That’s a conversation worth having openly rather than glossing over. But it’s less of a constraint than it sounds. Svelte’s learning curve is shallow enough that a developer who knows JavaScript tends to be productive in it within days, not months, because there’s less framework-specific ceremony to learn in the first place. That matters whether you’re a small studio pulling in a freelancer for a sprint, or a larger team bringing someone on permanently — either way, the ramp-up cost is genuinely low.
What this means for our clients.
Framework choice can feel like an internal, technical decision — the kind of thing that shouldn’t matter to anyone outside the engineering team. In practice, it shows up everywhere a client can measure:
Faster load times feed directly into Core Web Vitals, which feed into search ranking and, more importantly, into whether a visitor sticks around long enough to convert. A smaller, more coherent codebase means we can build features faster and with more confidence, which shows up as shorter timelines and fewer surprises in maintenance further down the line. And because the same framework can handle a static marketing page and a dynamic client application, we’re not asking clients to pay for a rebuild the moment their site needs to do more than sit still.
SEO in particular is one of the reasons SSR is our default rather than an occasional option. Most of our projects render server-side, with static generation used where content doesn’t need to change per request. Even client dashboards, which people often assume have to be client-rendered, we serve server-side using cookie-based auth — so an authenticated page still arrives from the server rather than being assembled after the fact in the browser. Anything that matters for search — the content a crawler actually needs to index a page properly — is delivered directly in the HTML response, not fetched in afterward. We’ll occasionally stream in secondary, below-the-fold content that isn’t critical to SEO or first impression, but that’s a deliberate choice for perceived performance, never a way of hiding content search engines need to see. It’s a small distinction, but it’s the difference between a site that merely looks fast and one that’s actually built to be found.
None of that is about chasing a trend. It’s about choosing infrastructure that keeps pace with a client’s ambition instead of quietly limiting it, the way Webflow eventually did for us.
Where we’re headed.
We’re already heavily using Svelte 5, and have migrated all projects originally built on Svelte 4, and its new runes-based reactivity model has continued the pattern we noticed from the start: less code to express the same idea, and a mental model that gets out of the way rather than sitting in front of it.
We didn’t set out to become a “Svelte studio.” We set out to build fast, maintainable products for our clients, and Svelte and SvelteKit turned out to be the clearest way to do that. That’s really the whole case — not that it’s fashionable, but that it keeps making the actual work easier and the actual outcomes better. So far, it hasn’t stopped.