I spent February using aidd to audit the code we’d been producing. There was plenty to fix. In Deeper, removing hardcoded seed data exposed problems in 25 features that had been marked passing.
The v2 rewrite
On February 1, I started Spernakit v2 from scratch rather than migrating v1 forward. Every v1 technology had been picked because I already knew it, and by this point I had a much better idea of what actually fit. The most important swaps were replacing Express with Elysia (Bun-native, type-safe end-to-end) and Prisma with Drizzle (no codegen step), and there were half a dozen more like that. The rewrite removed 58 dependencies. The first working v2 release landed six days later. Everything v1 taught me was still fresh, so there was very little wandering around. v2 carried forward the quality-gate approach from v1: bun run smoke:qc (typecheck, lint, build, format).
Over the next 10 days, v2 went through ten audit passes, each with a different lens - security, performance, dead code, and so on. Every audit emitted its findings as feature.json files in the backlog, and aidd worked through the backlog. In parallel, three apps got rebuilt from scratch on v2 instead of migrated, and the rebuilds beat the migrations every time. I already knew the behavior I wanted from each of them.
What the seed data hid
On February 20, removing module-level seed data from 20 Deeper backend services caused 25 features to regress. They had been returning hardcoded arrays. Without those arrays, the missing integration work became visible.
Remediation and re-verification brought Deeper back to 306 of 318 features passing, about 96%. That still left work to do, but the results were no longer resting on those hardcoded responses.
The rest of the month was the same loop applied everywhere. Spernakit hit 110/110 features, a security audit on the new DB admin panel caught a real SQL injection through unvalidated column names, an oversized route file got carved into domain modules, plus a pile of smaller fixes. The separate audit passes found things I had missed in review. Once filed as features, those findings could go through the same work queue.
Six apps on one template is past the point where I can honestly sync them by hand, and the v2 apps are already drifting in small ways. The template needs lifecycle tooling of some kind - shared type contracts between frontend and backend, a way to automate upgrades, validation that the API contract matches what the frontend believes.
Keeping the apps themselves in sync is the next problem.