Armakuni Contact us
← All case studies

A big report could freeze the whole application.
There was no budget for a rewrite.

An ethics and compliance software provider serves more than 500 companies, and its benchmarking reports could make its live Laravel application hang. Meanwhile a new survey product was running late ahead of a public demonstration, after a previous partner had gone over budget. Chosen from six vendors, our embedded pod repaired the reporting inside the existing application, taking report queries from minutes to seconds, and helped the survey product meet its demonstration.

Before

Benchmarking was the product, and it was stalling.

The new product was behind.

After
Secondsfor a benchmarking report, where it took minutes
  • The survey product met its summit demonstration, delivered by an integrated pod.

Benchmarking was the product, and it was stalling

More than 500 companies use the provider's surveys and reports to measure their ethics and compliance programs and compare themselves with peers. The on-demand benchmarking report is a big part of the value: a company can see that a 72% favorable score is normal if its peers average 71–73%.

That report ran inside a revenue-earning Laravel application, three years old and looked after by one in-house engineer who was about to leave. A large report, or several at once, triggered inefficient queries and resource bottlenecks, and the application would hang.

And the new product was behind

A separate survey product was approaching a customer-facing demonstration at the provider's annual global ethics summit, with delivery behind schedule. A previous partner had run over budget, and the internal team was struggling with onboarding, productivity and direction.

The team fixed the slow queries and bounded the load to keep the application running

A full rewrite was outside the budget, and the report was too important to leave broken, so the plan was to make the existing application work. The team cut the cost of the expensive queries, bounded how much work a single request could ask for, and put an integrated pod on both products working from one shared backlog.

How we built it

3 decisions, in the order we made them. Each one says what we did and why, with what it did drawn beside it.

  1. Make each query cheaper
  2. The workload was bounded so one customer couldn't stall the rest
  3. One pod for two products

Make each query cheaper

Built withLaravel
A report queryIndexesPartitionsRewritten queries
The engineering

The benchmarking workflow compares a customer's survey results with the provider's reference data, and large or concurrent reports were where it broke:

  • New indexes let the database find the relevant records with far less work.
  • The tables behind the reports were partitioned.
  • The most expensive reporting queries in the existing Laravel application were rewritten.

Report queries went from minutes to seconds, because the fix was there in the database the application already had, with no budget for a rewrite.

The workload was bounded so one customer couldn't stall the rest

A huge report, all at once 1234 Served bounded incrementsone customer can't stall the rest
The engineering

Usage limits let customers generate reports in increments within the application's capacity, so one very large request can no longer make the system hang for everyone. We reduced the cost of each query and bounded the report workload within the application customers were already using.

Why: customers can plan around a limit they can see. When the whole platform freezes, they have nothing to tell their own people.

One pod for two products

Built withLaravel
One pod Survey productLaravel app
The engineering

We began with an assessment, then joined a pod to the provider's team, working from a shared product backlog with technical leadership, sprint coordination and regular alignment to the roadmap. The pod worked across the survey product and the Laravel application, supporting the summit demonstration while keeping the revenue-earning application running. Development, maintenance and code-quality work stayed on the existing infrastructure.

What we'd tell another CTO

1With no budget for a rewrite, the team started in the database, putting indexes and partitions in first. They then bounded the work any one request could ask for, because customers could see a limit and plan around it, while a freeze would give them nothing to explain. The revenue-earning application kept running the whole time they fixed it.
2The two products shared one backlog so priorities stayed honest, and the team embedded with the client's team day to day, because that was how the stalled product made its date.

What else changed

  • Usage limits keep the application responsive under large or concurrent reports.
  • The provider evaluated six vendors, shortlisted three, and chose one team to work across both products.

What comes next

The survey product's continued delivery, and the Laravel application's technical debt paid down as the budget allows.

How we'd do it today

This project came before our current offers. Here's how we'd approach the same work now.

AK Evolve's AI analysis agents would score each part of the Laravel application on complexity, coupling, testability, change risk and AI readiness and put its tech debt in dollars, while characterization tests pin what the reports do today. When the budget allows the rebuild, each part would be replaced behind those tests, one at a time, so the reports never change unexpectedly, with the provider's engineers leading small crews of AI agents on AK AI Factory, every pull request passing the quality gates and a person reviewing and merging every change.

Have a problem like this one?

A free workshop: a few hours with the architects who'd do the work, on your own systems. No cost.

Book a free workshop