Spec Kit & Local LLMs: A hobby project

August 01, 2026

Trying to get some of the utopia out of the AI world

What the heck is KiddoTracker?

KiddoTracker is a React SPA that I built to replace a number of spreadsheets, texting threads, and pieces of paper pinned to my fridge. It tracks meals of various kinds, medicine doses & prescriptions, chores, screen time, and a mock bank account. Honestly, the actual substance of the app isn't so interesting so much as the fact that I had a number of things I wanted to track, and a fairly good idea of how I wanted to track them. It was very helpful to have the general user stories already in place.

Why did I build it

I'm in a weird place with AI. As a VP Eng, I'm well aware of the potential benefits to me and my team. I also wish I was having a greater impact on issues like climate change, power disparities & concentration, and the breakdown of our information ecosystem. So I'm torn in a lot of directions.

One of the more optimistic takes I've heard about a future full of AI goes something like this:

In a world where software is much easier to create, lay people don't rely nearly so much on centralized or commercial software. They create it themselves to meet their own bespoke needs.

I want a piece of this positive outcome. And I'm a pretty proficient software developer, if not exactly a web app developer. I should be able to figure this out if anyone can. I should be able to figure this out even if the tools I'm using aren't exactly perfect yet.

How did I build it

I set myself a few parameters from the outset. I didn't want to invest a whole lot of money in a simple experiment (I was much more willing to spend some time). I would much prefer to avoid cloud AI, which gives me the ick in climate and corporate power directions. So the tools I used could be run on my workstation, and I stuck to free tier products where I needed a product at all.

Local LLMs

I used primarily LM Studio and Qwen3 30B A3B 2507, with some Ollama Gemma4 31B thrown in for variety's sake. Qwen was the workhorse, and was far more responsive and capable when working on the actual code. Gemma was plenty useful when working on the specifications, but as the iterations of the project carried on and the model needed more and more context from the existing code, Gemma became less effective. I'm sure I can someday play around much more with how I run my local models to optimize their performance, but that is not a rabbit hole I've gone down just yet.

GitHub Spec Kit

This is probably the secret sauce of whatever success I had. Some of the lessons I learned along the way:

  • Speak in user stories. This is what the agent is going to create in specifications anyhow, I may as well skip a translation step and talk that way in the first place.
  • Use the clarify, analyze, and converge steps. While they aren't part of the core spec kit workflow, they did a fantastic job of keeping my dumb little local LLM on task and giving it the best shot at success.
  • A robust test suite is essential, and my local LLM is not great at it. It does a fairly good job of initially writing tests for a given feature, but they rot quickly without a whole lot of oversight: the agent was just as likely to break the test as correct the issue when dealing with a test failure. In particular, I never really got to a robust e2e (playwright) test suite. The e2e tests took too long for the agent to be really effective with it, and multiple workers against a local back end led to chaos and too much context for the agent to be able to effectively plan and implement an e2e test suite. Once I updated my project constitution to spend a lot more effort on unit & integration tests, the test suite became what it needed to me: a guard against regression as the agent continually makes dumb changes.

Supabase

Nothing but good things to say about Supabase. The free tier was more than enough for my little hobby needs. I did use the github integration to automatically apply migrations when merging to main, and I did use Supabase as both database and authentication back end.

Cloudflare Workers

Since my domain is registered with Cloudflare, they were a logical starting place. Workers integrates well enough with a github repo, so that kept my DevOps work to a minimum. And again, the free tier more than covers what I need for this app.

In the end

Now I have a nice web app that's become a daily driver for me and my family. It's fully featured enough for now, I can easily pick up where I left off and add more features as my kids grow out of the current feature set, and I don't have to cobble together a handful of commercial apps just to keep things straight.

I built it in a way that I'm happy with. I don't think the utopia I'm looking for is here quite yet, but if nothing else I learned a lot just by spending the time developing like this.

Nothing world-shaking. Just as it should be.

Visit →