Some projects start with a feature request. This one started with a risk nobody knew was there.
A European online-prescription business, two consumer brands running on one platform, came to us to pick the work back up. A previous team had built the core system and moved on, and it had run for roughly two years without anyone reviewing how it was actually put together. Before we added a single feature, we did what we always do first: we opened the hood and looked.
The 48-hour audit that reset every priority
Within two days of getting access, three things stopped us cold.
The server holding everything was 10 to 15 days from running out of disk. In two years, log files had never been rotated and not a single backup had ever been taken. About 30,000 patient records, names, addresses, phone numbers, medical conditions, prescriptions, and payment details, the most sensitive category of data there is, were sitting unencrypted in plain text. And a data feed was reachable from the open internet that returned those patient records to anyone who asked, with no login of any kind.
For a healthcare business, that is not a backlog. Under GDPR, special-category health data carries penalties up to 20 million euro, and this was wide open. We closed the exposed feed, encrypted the records, configured the first backups the platform had ever had, and relieved the disk pressure. Shortly after we closed the public feed, the server was hit with a denial-of-service attack, a strong sign the exposed data had already been found and harvested before we ever arrived. The first thing we delivered on this engagement was a breach that was quietly waiting to happen, and did not.
Making the platform safe to run, then trustworthy
An emergency clean-up came next: a focused hotfix that closed fifteen concrete holes, including a hardcoded master password left in the code, an unverified payment-confirmation step anyone could have forged, and several debug routes exposing internals, plus rate limiting so the login could not be hammered.
With the bleeding stopped, we modernised the platform properly, in thirteen planned phases rather than one risky rewrite. We moved the database to a more robust engine, restructured the code so pieces are cleanly separated and safe to change, and rebuilt the staff and patient screens as a fast modern interface. The number that matters most to a healthcare operator is this one: the platform now ships with 173 automated tests behind it. That is the difference between a system that works until the day it quietly does not, and one where a change tomorrow cannot silently break a prescription going out today.
How a prescription actually flows
The rebuilt core turns an online consultation into a signed, paid, delivered prescription without anyone re-typing between systems. A patient completes a medical questionnaire. The system creates the record and alerts the team. A doctor reviews it in their own dashboard and either approves and digitally signs it through a licensed e-prescribing service, or declines it with a note back to the patient. Payment is captured through Stripe and reconciled automatically to the right prescription. The finished document and confirmations go out on their own.
Underneath that simple story is real depth: around thirty distinct screens split across admin, doctor, and patient roles, with strict permissions so each person sees only what they should, and a clear separation between “took payment” and “issued a prescription” so the two can never be confused. It was built to be operated by a real team every day, not to look good in a demo.
Two brands, one system
The business runs two separate consumer brands, each with its own look, content, and pharmacy logic. Rather than build and maintain two parallel systems, we set it up so both run from one codebase that recognises which brand a visitor is on and serves the right experience. Adding or adjusting a brand is a settings change, not a second rebuild, which is why a third pharmacy-facing surface could be added later without starting over.
The pharmacy directory nobody had checked
A prescription is only useful if it reaches the right pharmacy, and the lists behind that had grown by hand over years. We audited all 88 live intake forms against the master directory of 2,259 pharmacy branches in a single pass, without touching the live forms.
It was worse than anyone assumed. One form had 90 branches from the wrong chain pasted straight in. Placeholder junk like “Other” and “choice 40” was sitting in real dropdowns. We found six branch-name misspellings duplicated across dozens of forms, and formatting inconsistencies that quietly split one real pharmacy into two. Each of those is a prescription heading to the wrong place or a dead end, caught before a patient ever hit it.
Rebuilding the public sites without losing the traffic
The three public marketing sites were still on an aging WordPress and Elementor setup, and it showed: the mobile pages took over 30 seconds to become usable, weighed down by hundreds of kilobytes of styling loaded on every visit, a real ranking problem for a health business Google holds to a high bar.
We rebuilt them on a fast modern stack, across a fixed-scope engagement of 242 hours that went through four review rounds before sign-off. The largest of the three sites came out to 101 pages with 4,772 internal links and zero dead ones. Just as important, we moved the content into a system the team edits by clicking, not by calling a developer. When we measured how much of each page was actually editable, we took it from 67 out of 100 to 86, wiring up things that had been hardcoded, including a consultation price that had been copy-pasted into roughly ten different places. And the sites relaunched with zero lost web addresses, so years of search history carried straight over instead of evaporating at cutover.
Recovering the marketing money that was leaking
Separately, the business was spending on ads without a reliable picture of what those ads produced. We rebuilt the tracking into one pipeline that follows a lead from first click to booked consultation across thirteen channels, feeding a single clean database instead of a scatter of disconnected tools.
The rebuild surfaced the leak immediately: 33 forms had never been connected to tracking at all, and a batch of submissions was being silently dropped. After a correction to a mis-set ad account, we recovered 215 conversions that the business had genuinely produced but had no record of, real bookings that had been invisible to their reporting.
Staying
The work did not end at launch. We monitor the sites and the systems in the background, so if something breaks, we know before a patient does. For a business where a broken checkout or a failed prescription is not an inconvenience but a real problem, that ongoing watch is the whole point.
The through-line across every block of this is the same. We did not hand over a demo and disappear. We found what the last team missed, fixed it before it detonated, rebuilt the core so it holds up, and stayed to keep it holding up.
If you have inherited a system nobody fully understands, our automation and integration work starts exactly the way this did, by mapping what is really there before touching anything.