Why I Built One Generic Engine Instead of Another One-Off Panel

Ever led a team and noticed that, over and over, everyone kept building almost the same thing, just for a different case? At some point you have to decide: do we build one more one-off, or do we stop and build the tool that gets the whole team out of that loop?

Between 2021 and 2023 I was a senior frontend developer and tech lead of a team of 7 at Alohub, a platform that built websites for real estate developers. Every developer wanted its own brand, its own sections and its own layout, and someone on my team had to build, section by section, the screen where that developer could edit its content.

At first that worked fine. But after the second or third new section type, I saw where we were headed. If we kept going like that, my team was going to spend the next few years building a different editing panel for every kind of content a client happened to ask for.

What I took away

• A pattern that repeats twice can still be a coincidence. The third time is the signal that something is worth building once and for all.
• The right abstraction doesn't save one person work. It saves the same work, forever, for a whole team.
• Building the hard piece well, once, is what lets the rest of the team ship fast afterward without thinking it through again.

The engine that turned a new panel into one row in a map

Instead of building a custom panel for every section type, I built one generic engine: about 15 reusable controls, a map saying which control edits which field, and a function that walks any path in the content to find the right value. Adding a new section type became one more row in that map. No new screen to build.

That engine is the core of the same framework that later saved the team 75% of development time on every new site.

Why not just build the panel they asked for?

Because building one more panel only solves that one request. The generic engine solves every request that hadn't arrived yet, but it only made sense to build once the pattern had repeated enough to trust it would keep showing up. Building it on the very first request would have been a blind bet.

What let my team move without me

Once the engine existed, adding a new section type stopped being a multi-day project and became an entry in a map plus a screen that already existed.

That's what the decision was actually solving. Not my own work: the work of the 7 people who depended on that foundation to move fast afterward.

I wasn't trying to save myself work. I was trying to save the same work, forever, for a whole team.

The same rule, now written down for my whole factory

That decision (wait for the pattern to repeat, then build the one piece that solves it for good) doesn't just live in my memory of what I learned at Alohub anymore.

I wrote it down as a real rule: don't abstract before the third occurrence, tolerate the second copy. It's one of the engineering rules I apply on every project I build now, including this very site.

Tolerating the second copy costs less than building the wrong abstraction.

If you lead a team, sooner or later you'll have to choose between building one more patch or stopping to build the piece that gets everyone out of the loop. I learned to watch for the third time something happens, not the first. Thanks for reading this far. 🙂