Component libraries scale poorly when every product has a different domain. We stopped hand-building admin screens — and started shipping admin panels in days instead of weeks.
Three years ago, the Rakton admin panel had hundreds of hand-written screens and components. Two engineers spent most of their time updating tables, forms and detail pages whenever something changed in the data model. The components weren't bad — they were just downstream of every business decision, and business decisions were constant.
We stepped back and asked a simple question: why are we hand-writing screens for information the platform already understands? A new field on an order means a new column in a table, a new input in a form, a new line on a detail page. None of that is creative work. It's mechanical. So we stopped doing it by hand.
Most component libraries solve the wrong problem. They give you well-designed building blocks — buttons, inputs, dialogs — and leave the assembly entirely to you. So every product team rebuilds the same structures: a table that loads data, sorts and filters it, paginates it. Multiply that by orders, products, customers, invoices, branches, users and roles, and you have a hundred slightly different tables, each with its own bugs.
We watched this happen at scale. Every new Rakton module started with a fresh table because the previous one had been customised in ways that didn't generalise. The library wasn't the problem. Hand-assembly was.
On Enravo Core, the business is described once, and the admin experience follows from that description. Lists, forms, detail pages and filters for an entity aren't written; they're there as soon as the entity is. When the business changes, the screens change with it.
Hand-built screens have a quiet security problem: every one of them has to remember who is allowed to see what. Miss a check on one page and confidential data leaks through the UI even when the API is locked down. When screens follow from the same rules the platform enforces, there's nothing to forget. Users see exactly what they're allowed to see, everywhere.
This isn't free. Generated screens give up pixel-level control. A customer profile with a hero card, a stats grid and an activity feed is a design decision, not a data listing. So we draw a line: the bulk of everyday admin work is generated, and the screens that define a product's experience — Rakton's dashboard, the POS register, customer-facing storefronts — are still crafted by hand, where they should be.
Schema-driven UI is a leverage tool, not a worldview. It pays off when you have many similar, data-heavy screens. It doesn't when:
We did it because we run several product lines on the same platform. For a single-product team, the same approach could easily be over-engineering.
Two years in, the Rakton admin covers far more of the business than it did. The team didn't grow, and neither did the amount of hand-written admin code. What was a downstream bottleneck became a structural advantage. That's what 'platform first' actually means: build the right foundation, and the products on top get easier over time, not harder. If your team spends its weeks rebuilding the same screens, talk to us about building on Enravo Core.
Platform, güvenlik ve mühendislik üzerine son makaleler.
A platform is a claim until something real runs on it. Rakton is the first product family built on Enravo Core — and building it changed Core more than we expected.
Devamını okuAssembling a stack from best-in-class services is the sensible default. Here is the specific reason we did the unreasonable thing instead — and what it cost.
Devamını okuA tablet on a shop counter is shared, public, and occasionally offline. Designing for it forced us to rethink what device trust means when the device is not personal.
Devamını oku