Your second data platform will be overengineered. Fred Brooks predicted this in 1975.
Brooks called it the second-system effect. The first system you build is constrained - limited budget, small team, unclear requirements. It works because you couldn’t afford to make it complicated.
Then it succeeds. And you get permission to rebuild it “properly.”
That’s where things go wrong.
Every shortcut from v1 becomes a requirement in v2. Every feature request that got declined becomes a must-have. Every “we should’ve done it this way” conversation becomes a design decision. The result is a platform that tries to solve every problem the first one didn’t - and creates new ones nobody anticipated.
It’s like replacing running shoes that feel broken in. The new pair looks better on the shelf. But you’ll spend weeks with blisters before they fit like the old ones did. I watched a team swap their entire stack because it ‘felt legacy.’ The replacement took 9 months. The pain points they wanted to fix? Three of them could’ve been solved with a config change.
Brooks’s mitigation is discipline, not avoidance. Resist functional ornamentation - not every deferred feature deserves a spot in v2. Make the cost of each addition visible in complexity, onboarding time, and maintenance. Put architects who’ve already built multiple systems in charge. Deliver in stages. Challenge every “while we’re at it” with a scope review.
I’ve been guilty of this myself - pushing for a clean rebuild when targeted fixes would’ve been faster and less risky. The teams that get v2 right treat it as migration, not revolution.
What’s the most overengineered replacement you’ve seen - or built?