We fix the
software
your business
runs on.

The single machine the whole company worked on had gone three years without a security update, because updates for it had stopped being made. It had never been restarted in almost three years, its main disk was 96% full, and its login had recorded more than forty-five thousand failed attempts. The software moved to hosting that can be kept current, exactly as it was, and the old machine was checked, emptied and switched off for good.

Read the full story →

Found

Three years without a security update, and no way to get one

Now

The same software, running where updates are still published

Every customer file the company held — uploads, documents, signed agreements going back years — lived on one machine and nowhere else. An old routine that was supposed to copy them elsewhere had been failing into a destination that no longer existed. The first thing the migration did was make a second copy, which was also the first real backup this data had ever had; today it sits under a daily backup with restore points kept for three months, and a restore has been performed rather than assumed.

Read the full story →

Found

The only copy of every customer file was on one machine

Now

Copied, verified, and backed up daily with tested restores

The lists staff live in — their own work, their own clients, this month's payments — were reading entire tables from top to bottom on every single load, because the software had no quick way to find the rows belonging to one person. One of those lists also re-counted a table of 829,000 rows once for every row it displayed. Nobody had reported it, because it had always been that way and slow is not the same as broken.

Read the full story →

Found

Six of the busiest lists read every row in the table, every time

Now

Direct lookups instead of full scans, and one count instead of thirty

A form collecting names, dates of birth and contact numbers had a second behaviour nobody had asked for: the address that accepted a submission would also list the submissions back, 3,788 of them, to anyone who knew how to ask. It was closed in the software itself rather than by unticking a permission, so that no future settings change can re-open it, and the now-meaningless permission was deliberately left in place as a second lock.

Read the full story →

Found

The form's own address would list every record it had ever taken

Now

Reading removed in code, so no setting can turn it back on

The public directory that the business exists to publish could be extracted in its entirety in about sixteen requests, because a single page request could be persuaded to return more than a thousand records at once. Automated traffic was doing exactly that, on a schedule. A guard now limits how much one request can pull, the edge blocks the pattern rather than counting it, and every real page on the site was replayed before and after to prove nothing a visitor does was affected.

Read the full story →

Found

The whole directory extractable in about sixteen requests

Now

Bulk copying priced out, ordinary browsing untouched

Releasing a change logged every user out and lost whatever they had half-finished, so releases were pushed to evenings and then postponed, which made each one bigger and riskier than the last. Sign-in state now lives outside the software, two copies always serve, and a release swaps them one at a time with an automatic undo if the new one misbehaves. Releases happen in the middle of the working day and nobody in the office can tell.

Read the full story →

Found

Every release signed all staff out and lost work in progress

Now

Releases mid-morning, nobody signed out, automatic rollback

Four payment providers were installed on a store that had taken more than 160,000 orders, and the plan was to rebuild the ones people remembered. One query over three years of orders showed that a single provider carried 94% of revenue and 98% of active subscriptions, while the one everybody named carried about two per cent. The same query surfaced the expensive part nobody had costed: the stored card details behind every recurring customer live with that provider and have to move with it.

Read the full story →

Found

The rebuild order was being decided from memory, not from the ledger

Now

One query, an afternoon, and a plan built on the actual numbers

One database served many separate customer organizations, under a rule that has to hold in every single place: organization A never sees organization B. Fifteen places in the software returned records without checking which organization was asking, clustered exactly where you would expect — in detail views and in listings written before the platform had more than one customer. Nothing crashed and nobody reported it, which is what makes this class of gap almost impossible to catch by reading changes as they go by.

Read the full story →

Found

Fifteen places returned records without checking who was asking

Now

One rule, asked at every point a record is handed out

Six outside systems sent automatic updates into the platform, and two of them were believed without question — the code that verified senders ended in a fallback that answered "valid" for anything it did not recognise. Nobody could have read records this way; they could have written false ones, which is quieter and more expensive to unpick. Verification went in over three stages so the platform never went down, and twenty-eight tests now cover forged and replayed messages.

Read the full story →

Found

The sender check ended in a fallback that answered "valid"

Now

Every sender verified on arrival; an unknown sender is refused

Two live paths in the software referred to parts of the system that no longer existed, left behind by a rename during an old restructure. One of them checked whether a component was available, found it was not, and returned an error — on every single request, for years. There were no bug reports, because people had quietly stopped trying. The references were corrected, the genuinely unwanted path was deleted rather than repaired, and the build now refuses a name that does not resolve.

Read the full story →

Found

Live code referring to parts of the system that no longer existed

Now

References corrected, dead paths deleted, the build now catches it

When a request failed, the software recorded the whole request so somebody could understand it later — which meant names, dates of birth and everything else the form carried, written into a file with weaker access control than the database it came from. A second, quieter version of the same problem was writing straight to disk, invisible to the logging settings entirely. One filter now sits on the single path every error already takes, and sixty-four tests keep it honest.

Read the full story →

Found

Failing requests wrote whole request contents into the log

Now

One filter on the path every error takes, with tests

The production database password, a payment provider key, mail credentials and several partner keys were sitting in files inside the code — and therefore in its history, in every copy anyone had ever made, and in every backup of those copies. Moving them into a managed store took about a day. The half that takes longer is rotation: until each value is reissued, the old ones are still live wherever they were copied, and that is the part this write-up refuses to round up.

Read the full story →

Found

Live credentials in tracked files, plus a backup copy of one

Now

Values injected at run time from a managed store, never in the code