Adtech
Campaign reports are slow. The team is busy. Fix the reports without a rewrite.
Representative engagement A typical project of this kind, drawn from how our team works. Figures are deliberately not claimed; ask us for a reference call instead.
Client shapeMid-sized US adtech platform
EngagementOne embedded engineer plus a reviewing lead
Typical lengthA few months, then ongoing
Usual stackPHP or Java API, MySQL/Postgres, React or Vue
Starts withCodebase Health & Speed Audit
The situation
Advertisers refresh campaign reports all day, and the reports have got slower as the data has grown. Every slow report becomes a support ticket and, over time, a churn risk. The in-house team knows it, but they're booked on the new bidding engine and nobody wants to touch a reporting path the original developers built.
What we do
- Profile the reporting path first, on a staging copy, and find the actual bottleneck: usually a missing index, an N+1 query in the report builder, or aggregation computed on every request instead of nightly.
- Put test coverage around reporting before changing anything, so the fix can't quietly break a number an advertiser relies on.
- Fix the real cause: rewrite the slow queries, add the right indexes, or introduce a pre-aggregation table that updates on a schedule.
- Ship as a series of small, reviewed pull requests the in-house lead merges, with no downtime and a rollback for each.
- Document the reporting data model the original team kept in their heads, so the next engineer doesn't need them.
What you get
Reports that load with the pageinstead of tickets about reports that don't
A roadmap team left alonethe bidding engine keeps its engineers
A documented data modeland tests that stay after we leave
Want proof, not a scenario?
We'll put you on a call with a current client working with us on something like this. Ask on the 30-minute call.
Transmission · next step
Have a similar problem?
Twenty minutes with a senior engineer, not a sales rep.