Why I Decided to Write My Latest API in SvelteKit (And Why You Should Too)
Matthias Bigl

Matthias Bigl

Dec 17, 2025

Why I Decided to Write My Latest API in SvelteKit (And Why You Should Too)

image.png

Let's be real for a second. Most "side projects" die in the git init phase. But mine? Mine actually evolved. And it taught me a massive lesson about Developer Experience (DX) that I need to share.

1. The Genesis: It Started with Hardware

To understand why I made these tech choices, you have to understand LoveLine.

It didn't start as a web app. It started as a Digital Picture Frame powered by an ESP32 microcontroller.

  • I put one on my girlfriend's desk.
  • She put one on mine.

The concept was dead simple: Intimacy through Hardware. I wanted a way to send a meme, a photo of my lunch, or a "thinking of you" message to her physical space without it getting lost in a sea of WhatsApp notifications.

2. The Evolution: The "Relationship OS"

To control these physical frames, I built a web interface using SvelteKit. But as I kept tinkering, that interface grew into something much bigger: a Personal Relationship OS. It became a cute, private playground where we could:

  • Control the physical frames (sending pixels to her desk).
  • Track relationship stats and unlock "Achievements" (gamifying our streaks).
  • Generate custom memes using AI.

It was the ultimate hobby project. The web app was the command center—a fast, realtime interface built in SvelteKit that managed everything from the hardware pixels to our shared digital history.

And this is where I fell in love. building LoveLine in SvelteKit felt like cheating.

  • The Filesystem Routing meant I never got lost in my own code.
  • Drizzle ORM meant my database felt like native TypeScript arrays.
  • Vite meant my changes were instant.

I wasn't fighting the framework; I was dancing with it.

3. The Accident: "Spark"

Then I got ambitious. I thought, “Since we have this connection, why not solve the Friday Night Argument?” You know the one:

"What do you want to eat?" "I don't know, what do you want?"

I built a feature called Spark. It was basically "Tinder for Ideas."

  1. We pick tags (e.g., Sushi, Cheap, Walkable).
  2. I hooked up an AI to generate date ideas based on those tags.
  3. We swipe Left/Right.
  4. It matches. We eat.

But then I looked at the database metrics. It was scaling too well. The AI wasn't just generating random text. It was building a Knowledge Graph.

  • Once the AI generated "Picnic at the Lake" for the tag Nature, that idea was saved.
  • The next time any couple clicked Nature, they got that idea instantly from the database. No AI call needed.

I realized: “This isn't a date feature. This is a Decision Engine.” This engine could help startups brainstorm features. It could help roommates pick furniture. It was a generic Group Brainstorming API trapped inside a romantic hardware/software ecosystem.

I had to split it out.

4. The Architecture: Two Services, One Language

I decided to extract Spark into its own standalone Microservice. now, the architecture looks like this:

  1. LoveLine (The Consumer): The original SvelteKit App + Hardware Controller. It handles Auth, Users, and the UI.
  2. Spark (The Engine): A headless API that acts as the "Brain" for brainstorming sessions. LoveLine just "ties into" it via API calls.

Now I had a choice for the Spark Engine. The "Enterprise Architect" on my shoulder whispered:

"Write the backend in Go! Or Spring Boot! You need a 'real' backend framework!"

But I looked at my LoveLine code. I looked at how fast I was shipping features. I looked at how much fun I was having with SvelteKit.

I thought: "Why not just build the backend in SvelteKit too?"

5. Why SvelteKit is the "10x" Choice for Backends

Most people think of SvelteKit as a frontend framework. They are wrong. SvelteKit is a high-performance, standards-based Node.js framework that just happens to render HTML.

I chose to use it in API Mode (no .svelte files, just +server.ts routes). Here is why it crushes traditional backend frameworks for DX:

A. The "Flow State" Workflow

Because LoveLine and Spark now share the exact same stack:

  • Copypaste Nirvana: I copied my drizzle.config.ts and auth helpers from LoveLine to Spark in 30 seconds.
  • Mental Context: I don't have to context-switch between "Java Mode" and "JS Mode". I stay in "TypeScript Mode" 100% of the time.
  • Shared DNA: Although they are separate services, they feel like siblings.

B. Type Safety That Actually Works

In SvelteKit + Drizzle, the database schema is the type definition.

export const ideas = pgTable('ideas', {

 id: uuid('id').primaryKey(),

 title: text('title').notNull(),

});

// Type is inferred automatically!

export type Idea = typeof ideas.$inferSelect;

If I add a column, every API endpoint that uses

Idea

updates instantly. No "drift" between DB and Code.

C. Zod (The Bouncer)

I don't trust inputs. Ever. For every single API endpoint, I write a simple Zod schema.

const VoteSchema = z.object({

 sessionId: z.string().uuid(),

 direction: z.enum(['left', 'right'])

});

This is my "Contract." It’s concise, readable, and saves me writing 50 lines of validations.

D. The Magic of $env

SvelteKit gives you two magical modules:

  • $env/static/private: Variables are loaded at build time. If DATABASE_URL is missing, the build fails. You literally cannot deploy a broken app. Best part? It’s completely type-safe. IntelliSense autocompletes your secret keys.

6. Software Architecture & The "Hobbyist Paradox"

There is a lesson here about Organic Architecture.

If I had started this project knowing exactly what it would become, I would have designed it differently. I would have built a Microservices Event-Driven Architecture from Day 1. And the project would have failed.

Why? Because it wouldn't have been fun.

In hobby projects, fun is the fuel. I chose SvelteKit for the backend because I fell in love with the workflow while building LoveLine.

  • Getting a "Hello World" in Spring Boot takes 40 minutes of XML and Annotations.
  • Getting a "Hello World" in SvelteKit takes 30 seconds.

I realized I didn't need a "Backend Framework." I needed a tool that got out of my way. SvelteKit is that tool.

Velocity is the only metric that matters.

Matthias Bigl

Matthias Bigl

Insert pretentious stuff about yourself here

Leave a Reply

Related Posts

Categories

Bigl's Blog

Personal blog by Matthias Bigl (Bigl) — Exploring technology, software development, and innovation.

© 2026 Matthias Bigl. All rights reserved.

Connect with Matthias Bigl

Bigl's Blog is the personal technology blog of Matthias Bigl, featuring articles on software development, web technologies, and tech insights.