Case Studies
Three engagements described in full, including what we got wrong on the way. Numbers are measured, not estimated.
Go, PostgreSQL with PostGIS, Kubernetes, Kafka
Rebuilding a dispatch engine that had stopped scaling
The situation
A European logistics operator planned routes overnight in a batch that took eleven minutes per depot. As volume grew the batch stopped finishing before drivers arrived.
What we found
We spent the first three weeks reading, not writing. The bottleneck was not the routing algorithm. It was a database query issued once per stop, inside two nested loops.
What we did
We extracted the planner into a Go service, replaced the per stop query with a single spatial index lookup, and moved the batch to a queue that could be run per depot on demand. Traffic was shifted depot by depot over nine weeks, with an instant rollback path at every step.
The outcome
Planning now takes nine seconds. The batch window was retired entirely, because planning can be run whenever a depot wants it. No downtime was required at any point in the migration.
Java, Kafka, PostgreSQL, AWS, Terraform
Taking a lending platform through its first regulatory audit
The situation
A lending startup had a working product and a regulatory deadline. Their ledger reconciled most of the time, which in financial services means it does not reconcile.
What we found
Reconciliation drift came from writing the ledger and the transaction in separate transactions. Under load, one could succeed while the other failed.
What we did
We rebuilt the money path around an append only ledger with idempotency keys and exactly once semantics through Kafka. Every mutation became an event. We added contract tests between services and a nightly reconciliation job that fails loudly rather than silently correcting.
The outcome
The platform passed its first audit with zero findings on the security review. Reconciliation has been exact for every day since the cutover.
Terraform, AWS EKS, Node.js, Redis, Grafana
Cutting a clinic platform's cloud bill by more than half
The situation
A clinic management platform was profitable on paper and unprofitable in practice. Infrastructure cost more than the engineering team.
What we found
Nothing was wrong with the application. It ran on oversized instances, kept three environments running permanently, logged everything at debug level into a paid ingestion tier, and had never had a single cache.
What we did
We instrumented before touching anything, so every change could be attributed. We right sized instances against real utilisation, moved non production environments to schedules, cut log volume by ninety percent by fixing levels rather than sampling, and added a read cache on the two endpoints that carried most traffic.
The outcome
The bill fell by fifty four percent within one billing cycle. Median response time halved as a side effect of the cache. Not one line of business logic was rewritten.
Every figure here was measured
Client names are withheld under our standard confidentiality terms. Any figure on this page can be substantiated on request, and we will introduce you to the client who lived it.
See the wider portfolioTell us what you are building. We will tell you what it takes.
No sales script. A working engineer reads your brief and replies with a scope, a team shape, and an honest estimate.