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.
For most of our existence, we have written about Enravo Core in the abstract. Identity that doesn't fall apart when a token leaks. Devices that earn trust instead of assuming it. Access rules that fail closed. All of it true, and all of it, from the outside, unfalsifiable. A platform nobody has shipped a product on is not a platform. It is a design document with good typography.
So we picked a real business, with real money moving through it, and built on top of Core until something broke. That product family is called Rakton, and this post is about what building it taught us.
The usual order is to build an application, watch it succeed, and then extract the reusable parts into a platform. We went the other way, deliberately. Security is not a layer you can retrofit. Once an application has shipped with leakable sessions, devices nobody can revoke, and permission checks scattered across the codebase, the cost of reversing those decisions is roughly the cost of rewriting the application.
Building Core first meant accepting a long period with nothing to demo. It also meant that when we did start building products, the hardest problems were already solved and solved once — not once per product, in slightly different ways, with slightly different bugs.
We wanted a domain that would push on every part of Core rather than flatter it. Small and mid-sized retail in Turkey turned out to be close to ideal. Money moves in cash and card and vouchers, often in the same transaction. Staff turnover is high, so device and permission hygiene matters. Connectivity is unreliable, so the system has to work when the network does not. And the regulatory surface — electronic invoicing, fiscal reporting — is unforgiving about correctness.
Rakton is four products sharing one foundation:
The point is not that these are four products. The point is that they are not four systems. A sale rung up on the register, an order arriving from a delivery aggregator, and a shipment leaving through the storefront all land in the same books, under the same access rules, with the same security guarantees.
The most useful thing about building on your own platform is the list of problems you do not have to think about. On the first day of Rakton, every app and channel already had its own identity and its own rules. Stolen sessions were already useless. Lost devices could already be cut off in one action. Who-can-do-what was already answered the same way everywhere, and every installation was already accounted for. None of that was Rakton work. It was Core work, finished earlier.
What that buys is not speed exactly — it is the ability to spend the schedule on the domain. Weighted sale rounding, partial payments, invoice numbering rules, courier zones: these are the things a retail product lives or dies on, and they are the things that get shortchanged when the team is still arguing about session handling.
This is the part we did not anticipate. We expected Rakton to consume Core. Instead it kept sending work back.
A register in a shop is not a laptop in an office. It is a shared device, operated by whoever is on shift, sometimes offline, physically accessible to the public. Our assumptions about devices had been built around the idea that a device roughly corresponds to a person. Rakton POS broke that assumption in the first week, and the fix was not a Rakton fix — it was a Core one.
The same thing happened with permissions. Core was built to fail closed, which is correct, and which is also intolerable when a cashier can't complete a sale because the shop's connection dropped with a customer standing there. Keeping the system strict while making that moment survivable was one of the more interesting problems we solved last year, and it exists because a real shop forced the question.
Every one of those corrections now belongs to Core, which means the second product will never encounter them.
Rakton is the first product built on Enravo Core. It will not be the last, and the way we work with it is the model for how we work generally: we build products on Core, we deliver solutions on Core, and over time we expect Core itself to be something partners build on.
For anyone evaluating us, Rakton is also the honest answer to the fair question behind every platform pitch. Not what could this run, but what does it run. It runs a business where a wrong number is a wrong amount of money, and where the person using it did not choose the software and does not care how it works.
That is a better proof than anything we could write about architecture. If you have a product that deserves the same foundation, talk to us.
Platform, güvenlik ve mühendislik üzerine son makaleler.
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.
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