Every CMS reaches a point where the workarounds outnumber the features. For us it was year three: a content model duct-taped into shapes it was never designed for, template logic split across four plugins, and a migration path that existed only in a spreadsheet nobody trusted.
The straw that broke the camel's back
The breaking point was mundane. A client asked for a second language on one section of their site — a reasonable request — and we estimated six weeks. Six weeks, because every template, every relationship and every preview path had quietly accumulated assumptions about a single-locale world.
That estimate wasn't a translation problem. It was interest on technical debt we'd been paying into for years, and it told us the foundation — not the feature list — was the thing to fix.
What we did differently
The rewrite started with invariants instead of features: structured content in plain collections, rendering through explicit templates, design decisions living in tokens, and no hidden state anywhere. Every feature we added afterwards had to justify itself against those invariants.
Six months in, the same multilingual request estimated out at four days. Not because we added translation features, but because nothing in the new foundation assumed a single language in the first place. That's the payoff of starting over that nobody puts on the slide: estimates stop being fiction.
Comments
Mara Jensen ·
This mirrors our experience almost exactly. The 'rewrite vs refactor' framing is the clearest I've read on the topic — sharing it with my team this week.
Aska Team ·
Thanks Mara! A follow-up digging into the migration side of the rewrite is in the works — stay tuned.
Tom Alvarez ·
Great read. How did you handle content migrations during the cutover — parallel writes, or a hard switch with a freeze window?
Leave a comment