Why We Build Our Own Software Before We Sell It

There’s a fairly common pattern in enterprise software: a vendor identifies a market problem, builds a product to address it, and sells it to organisations who become the first real test of whether the thing actually works. The vendor learns what breaks by watching it break in a paying customer’s environment. It’s a reasonable way to build a company. It is not how we build ours.

At Kerdos Analytics, every platform starts with a rule: we have to be the first customer. Before FloatInvest, CarnaPay, or any other platform is offered to anyone outside the Cedar Group, it has to solve a real, specific problem for one of our own subsidiaries — and it has to be treated as production infrastructure from day one, not a prototype we’re comfortable letting break.

We call this Build. Operate. Graduate. — three deliberate stages, in that order, for every platform we develop.

Build means finding a real pain point inside our own group and building the actual solution to it, not a proof of concept. If a system isn’t good enough for us to depend on internally, it doesn’t move to the next stage. There’s no external deadline pressuring us to ship something half-finished, because at this stage there is no external customer yet.

Operate means running that system across Cedar Group subsidiaries on real, live data — real payment volumes, real edge cases, real 2am failures. This is the stage that actually matters most, because it’s where theory meets reality. A payment system looks complete on a whiteboard. It only becomes trustworthy after it has processed real transactions, hit the edge cases nobody predicted, and been fixed under the pressure of an actual operational failure rather than a test environment. Every one of those incidents becomes documented, institutional knowledge — not a surprise waiting for whoever inherits the system later.

Graduate is the last stage, and the only one where anyone outside the group encounters the platform at all. After a system has been hardened by real operation, we license it to organisations facing the same problem we originally had. What they get at that point isn’t a promise about what the software should be able to do — it’s something that has already survived contact with reality, inside a company that had every incentive to fix it properly because we were the ones depending on it.

We think this ordering is a meaningful trust signal, not just an internal process preference. When a vendor asks you to be an early adopter of something untested, you’re implicitly being asked to absorb some of the risk of discovering what doesn’t work. Our model puts that risk on us, first, on our own operations, before it ever reaches a customer. It’s slower for us in the short term. We think it’s the honest way to build software that other organisations are going to depend on.

It also shapes how we talk about what we’ve built. Some of our platforms, like FloatInvest and CarnaPay, have graduated far enough to be built and entering the market. Others, like Kerdos OS and KAL Nexus, are still firmly in the Operate stage — running our own company today, with graduation a deliberate future decision rather than an automatic next step. We’d rather describe a platform accurately at whatever stage it’s actually at than oversell where it stands.

If you’re evaluating enterprise software from any vendor, it’s a fair question to ask directly: has this actually run on someone’s real operations, or am I the first? For everything we build, the honest answer is that we were.