Yet another personal project. I over-engineered it on purpose

Théo Verdiere — Tue, 06 Oct 2026 14:00:00 +0000

It started one evening, out of the ordinary friction of the job: the organizational and budgetary constraints that come with any system at scale, and never enough time to keep things clean and pleasant to work on.

Not a startup idea, not a side hustle with a monetization plan. Just a developer who'd spent a long time working inside systems he couldn't reshape, opening a fresh Kotlin project at 9pm because he wanted somewhere those limits didn't apply.

So yes, this is yet another personal project. The internet has no shortage of them. I knew from the start it would be oversized: a backend, an Android app, CI, infrastructure, a deployment. All for an audience of maybe six people. A bit of a champagne app on a beer budget.

The overkill wasn't the surprise; that part was deliberate. What I didn't plan was building a whole product. I started out just wanting to set up the infrastructure side myself, with something concrete running on it: a real frontend, a real backend, a real server.

By day I work on systems that serve tens of thousands of concurrent users, and I'd only ever seen most of that machinery from inside a job. I wanted to take it apart myself, in close-to-production conditions, on something that was mine.

It's been going for about 22 months now. What it became, and why I kept reaching for things it never needed, is the rest of this post.

The product, and the reason

Before going further, here's what all that infrastructure serves.

Grimoire is a place to keep your recipes and how-to procedures, which it calls Spells. Your Grimoire is private: the stuff you reach for every day. That's the part that's live today, Android-only, on the Play Store.

It's wrapped in a cozy fantasy theme: Spells, a Grimoire, an Academy. I wanted it a bit geeky so it wouldn't feel like more work at 9pm. It's mobile-first (you cook, hands dirty, the phone's already on the counter) and deliberately slow: no feed, no nudges. You don't fill a Grimoire in a day.

The rest is still being built. The Academy, a shared space where Spells get published, discovered and adapted: pull one into your own book, tweak it, share it back. A "lineage" view of how a published Spell gets forked downstream. Quests, for one-shot tasks. Guilds, smaller closed spaces to share within a group.

That's the product. Most of it could have shipped on a single rented box. The app needed some of what follows; most of it I built because I wanted each layer in my own hands rather than borrowed from a job.

The thesis

A personal project with no deadline and no boss is the easiest place in the world to over-engineer. I've come to think that's not a flaw. It's the point.

At work you ship the minimum: someone's paying, and it's not your time to gamble with. Strip that away and you can afford to try things and see what happens, with nothing lost if they don't pan out.

So I did the unreasonable things on purpose. Hexagonal architecture, which later let me swap search engines in a weekend. Zero-downtime deploys on an Elasticsearch I didn't need yet. A pinch of DDD while the app was young enough to absorb it.

You only learn what a pattern is worth once you've lived with it, even with an understanding as humble, and sometimes as shaky, as mine. What hexagonal and DDD actually looked like in this codebase is its own post.

None of this is advice: having no users and no revenue let me make trade-offs I couldn't defend at work.

Growing it one plateau at a time

I never planned this as a stack. It grew in plateaus, each opened only once the previous one felt solid, and usually because I'd hit a wall that made the next layer worth building.

Backend, alone, for three months. December 2024 to March 2025: just Kotlin and Spring Boot. I used the time to sit properly with hexagonal architecture and a contract-first OpenAPI spec. No client yet, just the shape of the system.

It was also where I really learned Kotlin and Gradle, and came to like how little Kotlin asks of you to get something clean working. I made my share of design mistakes in there too; some I only saw later, once a second layer started leaning on them.

Then it got a face. March 2025: Android with Jetpack Compose, built alongside the backend. Up to then the app had lived as a wall of requests in Insomnia; this is where it stopped being an abstraction.

A pipeline, earlier than I needed one. Around the same time, Dagger.io for CI: pipelines as real code, not YAML. Over-built in places, no question. But never wasted: it's what I run every day now, without thinking about it.

Infrastructure, in a sandbox first. Summer 2025: Pulumi, but on a local KinD cluster, not a live server. The same principle I lean on everywhere: the local environment should look as much like the real one as possible. So I got the deployment working locally before trusting it anywhere real.

Finally, a real server. August 28th, 2025: a Hetzner VPS running k3s. I did this the old way, on a deliberately bare box: cheap, and empty. Everything a managed platform hides was now mine to stand up by hand: reverse proxy, cert manager, the lot. The point wasn't hardship for its own sake. A managed control plane lets you stay theoretical about that whole sysadmin layer, and I wanted to actually meet it. (It did break, spectacularly, eight months later. The post-mortem gets its own write-up.)

From there it kept growing, driven by friction rather than a roadmap: Elasticsearch eating my VPS pushed me to Meilisearch; and since Spells are meant to be shared publicly, I built a small React admin to moderate them before opening that up.

Where it didn't go to plan

Deliberate overkill was only half of it. Plenty of the project came from the other direction: plans that met reality and bent.

I set up a full Karate E2E suite early, expecting to lean on it; later I admitted it was the wrong call for a project this size and tore it out. I ran three separate repos for a year, sure it was cleaner, until the workflow got painful enough to push me into a monorepo. Neither was a master plan. Both were course corrections, one from hindsight, the other from sheer fatigue. (The monorepo move gets a full write-up later in the series.)

Some of it was just blind spots. My backend habits had hidden a plain front-end fact from me: config gets frozen into the artifact at build time. It isn't read from the environment at startup the way it would be on a server. On mobile that's final; it ships embedded in the app. On web I could claw it back with a tiny Express server that serves the config at runtime. Either way I only hit it at deploy time, on the part of the project I'd filed under "the easy corner."

The landing page is the clearest case. It wasn't planned at all: I just needed somewhere to host the terms of service. I built a real one anyway, because I felt like it, but kept it cheap on purpose. Astro, pushed to Cloudflare Pages, built locally, done. No Pulumi, no Dagger pipeline. A small static site wasn't worth the maintenance, time and learning the backend was.

Wrapping it in the same machinery would have been absurd. (Cloudflare is exactly the managed, single-vendor thing I spent the whole infra effort pushing against. But a static site is portable because it's trivial: I can move it in an afternoon. I'll dig into where "provider-agnostic" actually holds, and where it doesn't, in a separate post.)

So the overkill dial wasn't set once and left there. It moved with what the project threw at me and what I had the energy for: studied on the backend, deliberately minimal on the landing page, and now and then just whatever I could be bothered with that month.

Where it stands

So where is all this now? The app is live, actually in production on a €10-a-month VPS, and it's been there a few weeks rather than sitting behind a "coming soon." A handful of friends and colleagues are the first real users. You can get it on the Play Store, or have a look at the landing page. The app, the CI toolkit and the landing page are public on GitLab; the infrastructure repo stays private, since it describes a cluster that's running.

Building the whole thing myself, from backend to cluster to landing page, is what finally made a system click for me, after years of only operating one slice of it. The rest is too specific for one post, so it's scattered across smaller ones: the k3s crash, Pulumi's portability promise, hexagonal and DDD in practice, the search-engine swap, where I drew the line with Keycloak, and the monorepo I backed into.

The other posts

The three-line config I shelved, and the three-hour outage it became (coming soon)
Building my infrastructure like I build software (coming soon)
Everyone has an opinion about DDD. I'd never had my own. (coming soon)
I swapped my whole search engine in a weekend. The domain never noticed. (coming soon)
What I let Keycloak handle, and what I took back (coming soon)
The API client I published and pulled, until a monorepo just built it (coming soon)