We just crawled out of an 8-month feature freeze on an e-learning platform. It was a massive slog. The total cost—calculating burn rate and lost velocity—was roughly $4.8M. The standard explanation was "technical debt," but when we actually dug into the codebase for the post-mortem, we found something interesting. It wasn't just messy functions or spaghetti code.
About 67% of the friction came from schema debt.
The problem wasn't the code; it was the "Architecture Decision Cascade." In Month 1, the team (5 devs) prioritised speed. They skipped Foreign Keys to avoid "annoying" constraint errors. They denormalised the user table to save a join. They used JSON columns for core domain data to avoid migrations.
It seemed smart at the time. But by Year 3, that compound interest hit hard. Simple features that should have taken two days were taking six weeks. Why? Because every single feature required the application layer to handle data integrity, which the database should have enforced for free. We weren't writing business logic anymore; we were writing defensive code to patch a leaky data model.
We decided we couldn't trust ourselves to design schemas under pressure anymore. The temptation to take shortcuts is just too high when you're rushing an MVP.
So we changed the workflow. We started using AI agents to generate the schema first, with strict instructions to enforce 3rd Normal Form (3NF), Foreign Keys on everything, and aggressive constraints. The AI doesn't care about "moving fast"—it just enforces structural correctness. We treat the schema as a strict contract that humans aren't allowed to soften.
The results after the refactor (tracked over 12 months):
- Feature dev time dropped from 6 weeks to 3 days.
- Incident rate dropped from 2.3/week to 0.2/week.
- Refactoring cost was ~$902k vs the projected $1.6M of patching the old mess.
To be clear, there are trade-offs. This approach feels restrictive. You can't just "hack" a feature out in an hour anymore; you have to define the data structure first. It kills the "quick and dirty" prototyping vibe, and you spend more time reviewing DDL than writing TypeScript. It feels slower on Day 1, but the data shows it's significantly faster on Day 100.
I'm curious if this matches others' experience with "tech debt."
- In your major refactorings, is the rot usually in the application code or the database schema?
- Is it ever actually worth skipping Foreign Keys for velocity, or is that always a trap?
- Has anyone else used LLMs specifically to enforce architecture constraints (rather than just writing code)?
It seems like we spend a lot of time talking about clean code, but "clean schema" might be the bigger lever.
Follow TheSSS AI for more !!
Top comments (0)