Production Check · Internal tools
Someone built it with ChatGPT. Now the company runs on it.
It started as a helper for one person. Six months later three teams depend on it, it holds customer data, and the only person who understands it is the one who prompted it into existence. Nobody decided this would be production. It is.
Book a 30-minute callWhat we do here.
This is the spreadsheet everyone depends on, rebuilt for 2026. The check looks at what a tool needs to be owned by a company rather than by a person: where the code lives and whether anyone else can get at it; whether there are backups and whether anyone has tested one; what credentials are sitting in the code; who can see what data; what happens when the person who built it is on holiday; and whether it can be run by someone who didn't write it.
Then we do the minimum that makes it ownable: a repository, a way to deploy it that isn't someone's laptop, secrets out of the code, access control, a page that explains it. Or, if the honest verdict is that it should be rebuilt properly, we say so, with a number, and the person who built it stays in the room for the rebuild, because they know what it's for.
What you get.
-
A written assessment in plain words: security, data, reliability, cost, and what happens when it gets popular
-
The must-fix items, fixed by us, in your codebase
-
A prioritised list of what can wait, and what to watch
-
One number: what it would take to go further, if you want to
-
Someone to call. That's the point.
How it runs.
1
Send us access
The repository, the hosting, and a thirty-minute walkthrough of what it does.
2
We check
Ten working days. We read, we run, we try to break it.
3
You get the verdict
A call and a document. Ship, fix first, or stop.
4
We fix
The must-fix list, agreed with you, done in your codebase.
Proof
A thirty-year-old scheduling product · twenty days, embedded
The one engineer who knew it all was retiring. Twenty days later, two others were working in his code.
A ten-person software company, a codebase started in the eighties, and every module owned by exactly one person. We embedded, built a feature that touched the oldest parts, left two hundred tests and a converter that moved their version control with its history intact. Then two of their developers worked, unsupervised, in code they had never seen, and one of them was closing tickets in the thirty-year-old core.
200 tests · 2 repositories migrated · 2 developers crossed over · 20 days
Read the caseThree questions.
- The person who built it is worried this is a judgement on them.
- It isn't. They built something people use, which is more than most projects manage. The check is about what the company needs around it, not about them.
- Should we just ban this?
- You can try. In our experience the tools appear anyway, because they solve real problems. Checking the ones that matter is cheaper than pretending they don't exist.
- Can this become a proper project?
- Often it should. The check tells you whether, and what it would take. If yes, that's a block of days, and the person who built it is the best product owner you'll find.
Price.
Fixed price: €2,900 excl. VAT, prepaid. Includes the check, the verdict within ten working days of access, and up to two days of must-fix work in your codebase. Further fixes at €900 per day, agreed before we start. If our verdict is "stop", the unused fix days are refunded.
Not for.
- An idea without code yet.
- A product nobody will use.
- Anyone who wants to be told it's fine.
- Two tools that don't talk. That's the Integration mission.
Tell us about Internal tools built with ChatGPT or Claude Code.
Lean builders. We deliver.