---
title: "The Spare Under the Mat"
date: "2026-06-23"
description: "I asked the outsourced firm running Boxhub's engineering for access to my own company's systems. They said yes, did nothing, and eventually deleted everything one night, never knowing we had already moved."
tags: ["leadership", "management"]
language: "en"
draft: false
---

Three weeks into the job, I asked a grown man for read access to my own company's source code, and he told me no, for my own good.

His name does not matter, so I will leave it out. He worked for the firm that ran Boxhub's engineering when I arrived as CTO, an outsourced team that had built our ecommerce and guarded it like a relic. We were on a video call. I had a list, and it was a boring list. Read access to the repositories. The deployment setup. A look at the database. The things you ask for in your first week, so that you can answer for the system you have just been made responsible for.

"Of course," he said, with the warm, frictionless smile of a man who has never once said yes to anything. "We will get that sorted for you."

Remember the warmth. Nothing happened for three weeks.

When I pushed, what arrived was not access. It was a read-only window onto a handful of old Jira tickets, and even those were lifeless, because the real conversation lived on their internal Slack. A private club, and we were not members. I could look at the tickets. I could not create one, or comment on one, or touch anything. No repository. No database. And then, after enough asking, their grand concession: a single machine where I was allowed to read the logs. Me. Allowed to read the logs. Read-only, naturally. My patience, by then, was about a centimeter deep.

It helps to know what I was there to do. I had been brought in to professionalize the technology and bring it under control: to set a real product and engineering vision with the execution to back it, the kind of foundation a business needs to scale up without cracking, and to be able to show all of it to investors when we went out to raise. That was the mandate. Every part of it started in the same place, knowing the system I had been handed. And that was the one thing they would not let me do.

The plan I gave them was plain: keep running the store, their real work, while we built the rest ourselves, mostly logistics. I needed to understand the thing I had signed my name under. You cannot lead a system you have not seen.

That request kept hitting the same wall, and after a while the wall started to tell me something.

I pieced the shape of it together from the logs and a lot of guessing, and it was not complicated. The store ran on Magento 2, the open-source ecommerce platform, with a layer of customizations on top. Production Magento had its own server. Its MySQL database ran on a second, the box I was not allowed near. The blog's CMS sat on a third. There was one staging environment too, its own Magento server, its own database behind it. Call it five machines, each one stood up by hand, MySQL installed straight onto the box, the domain parked in Cloudflare. No orchestration, no managed anything, nothing exotic. Once I knew where I was, the architecture was simple. The hard part had never been the system. It was getting permission to look at it.

The customizations were the interesting part. They were not in any repository I could see. At deploy time they were pulled in through Composer, the PHP dependency manager, from the firm's own repository. And the reason I had been given for being kept out, said to my face, was that they did not want us "making the mistake" of modifying Magento's code.

They were modifying Magento's code. Constantly. It was the whole job.

![Three-panel comic. Panel 1: 'I need access to the systems I'm responsible for.' Panel 2: 'We can't allow that. You might modify the code.' Panel 3: 'Modifying the code is literally your job. Which is exactly why you can't see it.'](/images/the-spare-under-the-mat/stonewall-strip.jpg)
*The exchange, in three panels.*

The secrecy was never protecting the system. It was protecting them. A vendor nobody can replace never has to compete on price, or speed, or quality again. Being indispensable is a real strategy. It is just a miserable one to be on the buying end of.

So I made a decision that, looking back, was the whole job in miniature. There was no real answer coming through the front door, I needed to understand these systems before I could govern them, and, the people who know me will confirm this, I have no patience. I stopped waiting and started working out how to do it myself.

I learned Magento. Not deeply, but enough. In a couple of evenings I could install it, deploy it, break it, and deploy it again, and somewhere in that loop the obvious thing landed on me: if I had the database, I could run the whole thing myself, with small fixes wherever I noticed something missing. The expertise I had been told to fear turned out to be a weekend and a bad attitude.

That left the database, the one box I had been refused. And here the firm did me a favor they did not intend. The machine they had handed me to read logs had an old Magento install sitting on it, left over from something. Magento 2 keeps its database connection in plain text, in a file called `app/etc/env.php`. Host, username, password, right there, in a folder they had forgotten about.

There it was. Our database. Our data, our system, and I was the officer the company had made responsible for both. They had locked every door in the building and left a spare key under the mat. The mat was a config file. It was called env. Dot. Php. I was not breaking into a stranger's house. I was finding out I had never been given the keys to my own. So I took a dump of the database, and from it, and from what I had learned, I rebuilt the whole thing on AWS.

The customizations were the last piece, and they hid in plain sight. I opened the project's Composer dependencies and there they were, a handful of packages under the firm's own name, pulled from the firm's own repository. The old copy on the log machine still had them. So I rebuilt our repository from that copy, turned their packages into ones we controlled, and put the lot under our own roof, so that nothing would quietly break the day their servers stopped answering. Then I built a real pipeline on top of our own repos, with the whole lifecycle finally in our hands, pointed it all at a quiet new domain, and tested it until I trusted it.

Then I re-pointed the live domain at the new servers and rotated the Cloudflare passwords.

For four days the entire company ran on infrastructure we owned and controlled, and nobody noticed. Not the customers, who saw the same store. And not the firm, who still believed they were the only people on earth holding the keys. Especially not the firm.

I did not announce it, and I stand by that. I had a duty to know my own system, and I had done it on the company's own assets, in daylight, deliberately. I also kept knocking on the front door the whole time, still asking, still doing my diligence, because the principle had not changed. I cannot answer to investors for a system I cannot see. I had to know.

Then, finally, the firm decided to cooperate. Or to look like it. An email arrived, warm as ever.

"As a gesture of partnership, please find attached a full dump of your database. Kindly confirm receipt."

I confirmed receipt. Two words: "Received, thanks." For weeks I had been pushing for a real audit, and this was where it landed. Confirming receipt.

The next morning, all of it was gone. Every machine they ran for us, deleted overnight. I called Cloudways, the host the firm had set us up on, to find out what had happened, and they walked me through it in the careful voice of a company that has just watched something it cannot undo.

"Someone logged in last night using the account owner's credentials," they said. "Over a VPN routed through another country. They deleted everything."

Nobody had stopped it, and from their side I understand why. The credentials were real and the login looked like any other, so to them it was just the company signing into its own account. Give or take a VPN and a border.

I set down my coffee. Then, because there was nothing else to do with it, I laughed.

The firm went quiet for two days. So I prodded them, the picture of innocence. "Do you have any idea what happened? It is all very strange." That got them to explain themselves.

"As part of our standard offboarding process," the email read, "we have returned your data and decommissioned the infrastructure. You are of course free to rebuild it yourself, or to engage us to do so in a new environment."

I could hear the smile in it. The same warm, frictionless smile from the first call, now explaining that burning our infrastructure to the ground had been a courtesy.

Offboarding. Nobody, in any meeting, in any message, on any day, had ever said the word offboarding. I had said exactly one word, many times, slowly, the way you repeat a word to a child. Audit.

Here is the part that turned a catastrophe into a story I can tell at dinner: it did not take us down. We had already moved. The live business was running on the setup I had quietly built, and the orders kept coming in. What they had deleted was a copy we no longer depended on. They had crept in at midnight, borrowed the boss's keys, driven across a border, and burned a building to the ground. The building we had moved out of the week before. They never knew we had left.

It is, hands down, the lamest sabotage I can think of. I have a theory about the why, and it is only a theory, so I will say so. I think they realized we had taken control and had not told them, felt the floor move, and reached for the kind of revenge that mostly burns the person reaching. I still do not understand why anyone would torch their own reputation over a client trying to learn its own stack. But people do, and you should plan for the fact that people do.

The bookkeeping was almost funny. We owed them around twenty thousand euros for recent work. Over the next two years we paid them one thousand, out of respect for the parts that had genuinely worked. And those customizations they had guarded like a national secret, I looked at them properly a few months later, once the dust settled. They did almost nothing of real value. We removed them ourselves, and built the right features the right way instead.

But the twenty thousand is not the lesson, and neither is the deleted infrastructure. The lesson was true before I ever walked in, and it is what made all of the rest possible. There was a contract when I joined, but it was the kind that protects whoever wrote it. The scope was vague, the terms were soft, our interests barely covered. It could be read whichever way suited them, so they read it their way. And a loose contract only becomes dangerous when the other side holds the leverage. They held all of it. They had the keys. That is what let them dare: hold our access hostage for weeks, then delete our infrastructure overnight and file it under "process." The paper did not stop them. It was never written to.

What this taught me, you can have for free. A real partner wants you to understand your own system, because their value is the work, not the secrecy. When the pitch is that you must not be allowed to see how the thing works, that is not expertise. It is a hostage situation with better manners.

And the first job, before the strategy and the roadmap and all the parts that feel like the title, is to actually know and own the system you are accountable for. Not a diagram of it. The thing itself: where it runs, who holds the keys, what happens on deploy, and what exactly you would lose at three in the morning if a vendor decided to be petty. If you cannot answer that, you do not run your system. Someone else does, and somewhere, quietly, they know it.

I learned mine because I had no choice. The curiosity was real too, but the choice came first. I would recommend learning it before someone forces you. The morning you can rebuild it yourself is the morning nobody can hold it over your head again.