The problem, and what it cost
The platform went down, and it went down at the times it was needed most. Its customers are institutions that must be able to reach families at short notice, so an outage is not an inconvenience — it is the product failing at its one job.
It was also failing security audits. Customers were asking questions the business could not answer with a straight face, and deals were held up waiting on assurances that could not honestly be given.
The cost was renewals at risk, engineering time spent firefighting instead of building, and a sales conversation that started from behind.
The outcome we agreed to measure
The agreed measures were availability and the audit result. Passing the audits the platform had previously failed was the explicit target, written down before work began.
Availability was baselined from their own incident records.
What we built
The application was rearchitected for high availability: no single point of failure in the paths that matter, failover that has been tested rather than assumed, and recovery procedures that someone other than the original author can follow.
Security was hardened across the stack — access control, data handling, secrets, patching, and the evidence trail auditors ask for. The controls were designed so they can be demonstrated, not just claimed.
The work was staged so the platform kept serving customers throughout. No big-bang cutover.
The number
failingtopassing
Security and availability audits, before and after the rebuild.
Where it runs now
The rebuilt platform is in production and now passes the audits it previously failed. Outages are no longer the thing the team plans its week around.
We continue to support it.
Different business, same shape of problem?
That's usually how these start. Tell us what the process is costing you and we'll say whether it's worth building for.