Software engineering
Architecture and delivery for systems that have to hold up under load
A bounded project, with a dated end
What it covers
Architecture and design
Target-state design for distributed systems, and the decision record that goes with it. Days to weeks, and the deliverable is a document and a decision you can act on.
Diagnosis under load
Finding out why a system falls over when it gets busy — and proving the answer with instrumentation rather than argument.
Building the system
JVM delivery where the hard part is concurrency, state or throughput rather than screens and forms. Java 21, Spring Boot, Kafka, Redis, Postgres.
Legacy modernisation
Moving an existing estate toward something that can be changed safely, in increments that each stand on their own.
The problem this is for
A system that was fine at one scale and is not fine now. Latency that spikes without a clear cause. A component everyone is afraid to change. An estate where adding a feature means touching six services and hoping.
Those are the engagements where the work is worth what it costs. If what you need is a straightforward application built to a specification, you do not need us.
Architecture-led, and small on purpose
We are a small team, so we work at the end of the market where a small team is an advantage: the architecture and the hard problem, rather than the large delivery programme.
A typical engagement is weeks to a few months and produces a design, a working proof, and enough transferred understanding that your team owns it afterwards. We would rather scope something that ends than be embedded indefinitely.
Where the depth is
Distributed and event-driven systems on the JVM — message streaming, cache and state coordination, server-sent event fan-out, the awkward parts of concurrency. Our own platform runs on Java 21 with virtual threads in production paths, and our performance work is written up rather than remembered, including the parts that turned out wrong.
That last point is the one worth pressing on. Anyone can claim distributed-systems experience. Being able to show the instrumentation trail of a fault you found, and the two answers you discarded on the way, is a different kind of claim.
What we will tell you early
If the problem is not in our depth, we will say so in the first conversation rather than the third invoice. Turning work down is how the rest of this stays true.
What is behind the claims
Each of these names the work that demonstrates it, rather than asking you to take it on trust.
- We build systems that hold up, and we can show the numbers
- 2,500 concurrent game sessions and 10,000 connected players, zero failures, on four bare-metal desktop-class machines totalling 40 cores that were simultaneously running the load generator, our CI and the rest of our platform. It is the largest run the hardware allowed, not the point where anything broke.
- The diagnosis is the skill, not the throughput number
- Reaching it meant finding a message-consumption ceiling and a self-inflicted thundering herd — located by instrumenting the delivery path, after two confident hypotheses were refuted by the measurements and abandoned.
- We test at a depth that shows up later
- 3,668 automated tests across our own systems, including suites that run against real message brokers, real databases and real browsers rather than mocks.
- Our own language builds a production service
- The state machines in our mahjong platform are generated at build time from declarative source and persisted through that engine in production — not a demonstration project.
What we decline
- Generic application development. Plenty of firms are better placed for it, and cheaper.
- Staff augmentation and time-and-materials placement. We take projects, not seats.
- Front-end and mobile application delivery.
Next
If any of this describes what you are dealing with, tell us about it.