How to read these case studies
Each write-up follows the same shape, because it is the shape that answers a technical buyer's questions in the order they occur to them: the problem as the client stated it, the constraints that were fixed before we arrived, the architecture we chose and what we rejected, the parts that turned out harder than scoped, and what the system does now. The architecture section is the one worth reading. It is where a supplier either demonstrates that it understood the domain or reveals that it built whatever was asked for.
They are deliberately not written as success stories. Several describe a decision that was reversed, a scope that was cut, or a recommendation that reduced the size of the engagement. Those are the useful parts, and a portfolio without any of them is a marketing document rather than an engineering record.
What the nine engagements have in common
They span banking and payments, healthcare, government and enterprise manufacturing, which look like unrelated sectors and are not. In every one, the software is inspected by somebody other than its users: a regulator, an external auditor, a payment scheme, or a procurement office. That single property drives most of the engineering. It is why the transaction stores are append-only, why the audit logs are queryable by subject and by time instead of only chronologically, and why the decisions of record are produced by deterministic rules with a model kept off the critical path.
The second commonality is that integration, not feature development, consumed most of the effort. Connecting to a core banking system, a national identity service, a hospital information system or a tax authority means accepting an interface you do not control and cannot change. We write about that pattern in more depth across the industries we serve, and the engineering practices behind it on the compliance, fintech and healthcare service pages.
What we can evidence, and what we cannot
Every engagement below is covered by a non-disclosure agreement, so clients are described by category and sector rather than named. We are not able to publish logos, contract values or named references, and a supplier in this sector who does publish them for regulated clients is worth a question about how that was permitted.
Where a case study states an outcome, that figure is reported by the client and has not been independently audited, and it is marked as such rather than presented as a verified result. What we can evidence directly is the engineering: the standards each system was built to, the architecture decisions and their rejected alternatives, and the integration surfaces involved. Those are described precisely because they are the parts we are accountable for.
If you want to test any of it, the fastest route is a technical call. Bring an architecture you are considering and ask an engineer to pick holes in it. You will learn more about whether we know this domain in forty-five minutes than from any number of case studies, including these.
