Full-stack Svelte development
SvelteKit and Svelte 5 front ends on a typed API, with a Django or headless Wagtail backend behind them.
Some things should not be a server-rendered page. An editor, a planner, a dashboard someone keeps open all day — interfaces with real state in them. Svelte is what I build those in, on a Django or headless Wagtail backend.
Why Svelte and not React
Because the alternative to a single-page application is usually not another single-page application — it is admitting you did not need one. Most of what gets built in React would be simpler, faster and cheaper to maintain as server-rendered HTML with a little JavaScript.
When you genuinely do need a client-side application, Svelte asks for less: no virtual DOM, less shipped JavaScript, and reactivity you can read off the page rather than hold in your head. SvelteKit gives you server-side rendering and routing without a separate framework decision. That matters most on the projects where nobody will be paying a frontend specialist to babysit the build for the next five years.
How I build it
The architecture, concretely:
- SvelteKit 2 with Svelte 5 runes for the frontend, server-rendered where that helps and client-side where it has to be.
- Django or headless Wagtail behind it. The backend keeps the domain model, the permissions and the content. Wagtail stays a genuinely good editing interface even when it is not rendering the pages.
- A typed client generated from the OpenAPI schema, so the frontend and backend cannot drift apart quietly. A renamed field is a build error rather than an empty box in production.
- Tailwind for styling, because a design system in CSS that nobody documents is a design system that decays.
- Passkeys where authentication should stop involving passwords.
The unglamorous part is the seam between the two halves. That is where these projects usually go wrong, and it is why the typed client is not a nice-to-have.
Two decisions I make early on every one of these. First, what has to work without JavaScript — because "the whole thing" and "none of it" are both wrong answers, and the honest one is usually that navigation and reading should, while the interactive parts need not. Second, where the state actually lives: state duplicated between the server and the client is the single most reliable source of bugs in an application like this, so the less of it there is, the better.
What you end up with
- An interface that feels immediate, because it is not re-rendering a page to change one number.
- A backend you could put a different frontend on, or a second one — a mobile app, a partner integration.
- A contract between the two, enforced by types rather than by documentation nobody reads.
- Substantially less shipped JavaScript than the React equivalent, which your users notice and your Lighthouse score agrees with.
One consequence worth planning for rather than discovering: going headless means two things to deploy instead of one, and a version skew between them that server-rendered Django simply does not have. It is manageable — and it is a real cost that should be weighed before the architecture is chosen, not after.
Being straight about this one
Svelte is the newest thing on this list of services and the public case study for it is not live yet — a headless Wagtail and SvelteKit rebuild that has not launched. When it does, it will be here with everything else.
The backend half has a long track record, and it is on the Django development page. If you want to talk to a reference about the Svelte work specifically, ask me and I will arrange it rather than pointing you at a page.
Talk it through
Get in touch and describe the interface you have in mind and what has to be behind it. If the honest answer turns out to be that you do not need a single-page application, I would rather tell you that early.