Assembling 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.
The advice is close to unanimous, and it is good advice: do not build your own authentication. Do not build your own permission system. Buy identity, buy billing, buy the parts that are not your product, and spend your time on the thing that makes you different.
We built Enravo Core anyway. Not because we thought the advice was wrong, but because of what we wanted to be different about.
When you assemble a stack, each component is usually excellent. The identity service is better than most teams would write. The rules engine is mature. The device management is battle-tested. The trouble is not the components. It is the space between them.
Security failures rarely happen inside a well-built component. They happen at the joins: the session that one service considers verified and another considers merely well-formed, the permission that is enforced in the API but not in the background job, the device that identity knows about and the audit log has never heard of. Every seam is a place where two systems hold slightly different beliefs about who is doing what.
With four or five separate services, you do not have one security model. You have four or five, and an integration layer whose job is to pretend otherwise.
Our goal was narrower than building everything ourselves. We wanted one place where the following facts are decided, and only one:
None of those four requirements is unusual on its own. What is hard is making them agree, permanently, across every product you will ever ship. That is what Core is for, and it is why it lives at the bottom of the stack rather than beside it.
This decision is expensive and we would be misleading you to pretend otherwise.
It cost us time before we had anything to show. It meant taking on maintenance that someone else would otherwise carry, including the unglamorous parts nobody demos. It means when something in Core is wrong, nobody is coming to fix it for us.
It also means we own our own upgrade path. No pricing change to someone else's enterprise tier reshapes our product. No deprecation notice sets our roadmap for a quarter. No security posture is inherited from a company whose priorities are not ours.
We are not arguing that everyone should do this. If you are building a single product and looking for fit, assembling is almost certainly right, and building your own platform is a way to spend a year proving nothing.
The calculation changes when you intend to ship several products that must share one security posture, when the products handle money or regulated records, when devices in the field are part of the trust boundary, and when the relevant question is not whether you can build the feature but whether you can still explain the system in three years.
That was our situation. Core is the answer we chose, and it is the reason the tagline is not a slogan: secure by architecture means the security decisions were made once, underneath, where a product team cannot accidentally opt out of them. If that's your situation too, you don't have to make the same investment — 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ı 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ı okuComponent 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.
Devamını oku