Why I Built One Editing Engine Instead of Another Custom 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 client 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 client 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.
• A useful abstraction, a shared solution to a repeated problem, can save the whole team from doing the same work again.
• Getting that shared foundation right lets the team add features without solving the same problem each time.

One editing engine for different kinds of content

Instead of building a custom panel for every section type, I built one generic engine: about 15 reusable controls, a configuration mapping each field to a control, and a function that finds the right value within the content. Adding a new section type became one more row in that map. No new screen to build.

At Alohub, the framework built around a shared editing engine reduced development time for new sites by 75%.

Why not just build the panel they asked for?

Because another custom panel would solve only that request. A shared engine could handle similar requests too, but it was worth building only after we had seen the pattern repeat. On the first request, we would still have been guessing what those requests had in common.

A foundation the team could build on

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 was the point of the decision: give the team of 7 a foundation they could use to add sections without rebuilding the editor each time.

A shared editing engine saved the team from rebuilding a panel for each new section type.

The same rule, now written down for my whole factory

I still use the same approach: wait for a pattern to repeat, then build a shared solution. What I learned at Alohub is now written down.

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. 🙂