- Home
- Case Studies
- Ouch Learning and Development
Ouch Learning and Development
Training and consultancy specialists · Bournemouth
Taking on the custom application the whole business runs on - then modernising it while it stayed live.
Visit websiteOuch Learning and Development is a training provider based in Bournemouth. Their enquiries, quotes, bookings, course delivery, delegates, certificates and invoicing all run through one custom application – the Ouch Portal. We look after it.
Ten months, ongoing
40+
releases in ten months
2,400+
automated checks, built from zero
68,000
lines of inherited code, now documented
The Challenge
Ouch runs on one piece of software. The Ouch Portal handles the whole lifecycle of the training business – enquiries, quotes, bookings, course delivery, delegates, certificates and invoicing – and it talks to Microsoft 365, Xero, Stripe and SharePoint to do it. If the Portal stops, the business stops.
When it came to us, nobody could tell us how it worked.
We inherited roughly 68,000 lines of PHP across some 556 files, written without a framework, with no documentation, no automated tests, no deployment pipeline and no managed database structure. Everything anyone knew about how bookings, statuses and workflows actually behaved lived inside the code itself. There was no way to check whether a change had broken something until a member of the team hit it in the middle of their day.
There was a commercial cost running quietly underneath all this, too. When the link to Xero failed partway through, it would try again ten minutes later – and create the same invoice a second time. Then a third. Someone had to spot it and clean it up.
The brief was not “rewrite it”. Ouch needed the Portal working every day, and they needed new things from it. So the challenge was to modernise a large, opaque system while keeping it live and continuing to ship the features the business was asking for.
When it came to us, nobody could tell us how it worked.
The Approach
Big-bang rewrites of business-critical software are how companies lose a year and their nerve. We didn’t propose one.
Instead we started by making the system knowable. You can’t safely change code you don’t understand, so before we changed much of anything we read it, mapped it and wrote it down. Then we built the safety net – automated tests and an automated pipeline – so that every change after that point could be checked by a machine and driven by a human in staging before it reached anyone at Ouch.
With that in place, we worked in a deliberate order. Protection first: we measured the Portal against current security standards and brought it up to them, before building anything new on top. Live error monitoring next, so real problems reached us before the team had to report them. And throughout, a steady drumbeat of small, tested releases rather than occasional large ones – or the live code surgery the team had been used to – each update easy to check, easy to roll back, and boring to deploy.
New features were never parked while this happened. Modernisation the business can’t see is a hard thing to justify, so the finance and scheduling work Ouch wanted shipped alongside it.
Big-bang rewrites of business-critical software are how companies lose a year and their nerve.
The Solution
The work fell into three layers, built in that order.
First, making the Portal knowable. We wrote a full internal reference covering the architecture, the business workflows, the task queue and every external integration. Project guidance now captures the rules and conventions that matter, so good practice survives any one person.
Second, the safety net. The test suite went from nothing to more than 2,400 automated checks – unit tests and full browser-driven end-to-end tests – running on every single release, on a deliberate march towards 80% line coverage. These aren’t decorative: several genuine bugs were caught by the tests and fixed before anyone at Ouch ever saw them. Alongside them, eight-plus automated workflows now handle testing, deployment and releases, and the database structure is managed as code, with a check that fails the build if the live structure drifts from what the code expects. There’s also a forward-compatibility scan, so progression towards moving off the old version of PHP is mapped rather than looming.
Third, everything the business actually asked for. Finance and scheduling features shipped throughout, on the same cadence as the modernisation work – never parked behind it.
A change is now small, checked by machine before a person sees it, and boring to deploy.
Protection built in, and kept up.
We reviewed the Portal against current security standards and hardened it accordingly: tighter access controls on every action, modern handling of incoming data, signature validation before a quote can be accepted, and payment configuration in protected storage. That work is now tracked openly and revisited as routine, so the Portal stays protected as standards move on.
Errors that find us, not the other way round.
The Portal now reports its own errors straight to us, and we work through them on a set routine: real faults are separated from noise, logged, and fixed. The loop from someone hitting a problem to the fix going live is closed and repeatable.
Invoicing that behaves.
The Xero sync paces itself to stay inside Xero's daily limits and prioritises the invoices actually waiting. A booking is invoiced once - duplicates are gone, and nobody in Finance spends their time spotting and unpicking them.
The busiest screens, faster.
We tuned the database behind the screens the team lives in - calendars, customer lists, enquiry lists and invoice syncing - so they respond quickly instead of making people wait.
Staff Availability
One screen for holiday and absence, which warns you when you're about to schedule someone to teach on a day they've booked off.
Invoice Pipeline
A Finance view showing exactly where every booking sits on its way to becoming a Xero invoice. "Why hasn't that invoice appeared yet?" is now a glance, not an investigation.
Split invoicing
Grant bodies can be billed a fixed amount or a percentage per delegate, with the remainder going to the customer automatically.
Enrolment campaigns
Campaign dates that invoice themselves on the morning the course begins, an online agreement the customer signs before anything is billed, a redesigned roster screen, and a one-click way to free up a seat when a delegate drops out.
The Results
Ten months on from the first commit in October 2025, the Ouch Portal is a documented, continuously tested, continuously released product – and it never went off the air.
Behind that: around 1,460 commits and more than 130 reviewed changes by a very small team, from the first release candidate through to v1.3.7 in August 2026. Anything we find is logged, visible and worked through in priority order, rather than surfacing one surprise at a time.
What that means for Ouch day to day is quieter. Finance stopped chasing duplicate invoices. The busiest screens got faster. Errors get fixed before they get reported. And when the business wants something new from the Portal, it’s a conversation about scheduling, not about risk.
When the business wants something new from the Portal, it's a conversation about scheduling, not about risk.
Where the Ouch Portal was, and where it is now.
Documentation
None
Full architecture, workflow and integration docs
Automated tests
0
2,400+ checks on every change, 80% coverage target
Test and deploy pipeline
None
8+ automated workflows
Database structure
Artisanal
Managed as code
Security
Not previously reviewed
Hardened to current standards, reviewed as routine
Error visibility
None
Errors reported automatically, logged and fixed
| Dimension | Before | After |
|---|---|---|
| Documentation | None | Full architecture, workflow and integration docs |
| Automated tests | 0 | 2,400+ checks on every change, 80% coverage target |
| Test and deploy pipeline | None | 8+ automated workflows |
| Database structure | Artisanal | Managed as code |
| Security | Not previously reviewed | Hardened to current standards, reviewed as routine |
| Error visibility | None | Errors reported automatically, logged and fixed |
Inherited Oct 2025 → today (Aug 2026)
A note on how we did it
A large legacy system, modernised while live, with new features shipping throughout – by a small team in ten months. That pace comes from an AI-augmented engineering workflow: purpose-built automation drives the repetitive but valuable work, including error triage, bug-fixing against reproductions, incremental test-writing and release notes. A human engineer stays in control of the design, the review and every single merge.
It means our clients get the throughput of a much larger team, with the judgement of people who know their business.
“Quote to be confirmed”
Kim and Gemma, Ouch Superstars
Moving Forward
We’re still shipping. The release cadence continues, the coverage target is still being worked towards, and the error routine runs every week. Next is completing the move to a current version of PHP – already mapped by the compatibility scanning we put in place, so it’s a planned piece of work rather than a cliff edge.
This is what a long-term partnership around a custom application looks like: someone who knows the system properly, keeps it safe and current, and turns “can it do this?” into a shipped feature.
