Internal tools are the best case for an AI builder. The requirements are known, the users are down the hall, and nobody is going to churn over the empty state. We recommend them for exactly this, frequently.
They are also where we find the most alarming things, and for a structural reason: an internal tool stops being an experiment on a specific day, and nobody marks it. One morning somebody's job depends on it, and the tool has no idea.
Four things change on that day
1. One permission level stops being enough
Version one has a single role: staff. Everyone who can log in can see everything. That is correct and sensible for three people who all do the same job.
Then you hire a contractor. Or an intern. Or a regional manager who should see their branch and not the other four. There is no way to express that, so you either grant them everything or exclude them and run things for them by hand. Both are wrong, and the second one quietly makes you the bottleneck.
Retrofitting record-level permissions is the most common internal-tools engagement we run. It touches every query, which is why it is a project rather than an afternoon - and why it is dramatically cheaper before the third role exists than after.
2. Somebody asks who changed a number
Finance, an auditor, or a customer dispute. Who changed this price? Who approved this refund? Who deleted this record?
An app that stores current state cannot answer any of them. And unlike almost everything else on this list, you cannot fix this retrospectively - adding an audit log today tells you nothing about last quarter. The history that was not written down does not exist.
3. It becomes a system of record
Data starts existing in the tool and nowhere else. Notes, statuses, approvals, attachments. At that point the tool is not a convenience over the real system - it is the real system, and backups, retention and export stop being technical hygiene and become a business risk with your name on it.
The question to ask is simple and uncomfortable: if this disappeared tonight, what could we not reconstruct? If the answer is anything at all, then point-in-time recovery needs to be on and you need to have actually performed a restore. An untested backup and no backup are the same thing on the day you need one.
4. Somebody leaves
Internal tools rarely get single sign-on, because the first version did not need it. Access lives in a users table that nobody thinks about, so offboarding removes someone from the directory, from email, from the cloud console - and not from the tool that holds your customer list.
The related version of this is worse: the tool was built by one person, in their personal account, on their builder subscription, pointed at a database in their name. When they leave, the tool keeps running and nobody can change it. We have been called in for exactly this more than once, and the recovery is much harder than the prevention.
“It is internal, so does security matter?”
Two questions decide it. Does it hold customer data? Does anyone outside your permanent staff have an account? If both are yes, an internal tool is an external attack surface with an internal name.
And most internal tools we audit are reachable from the public internet with a password in front of them and nothing else - no IP restriction, no second factor, no rate limit on the login. "Internal" is describing who it is for, not where it is.
- Put it behind single sign-on so the directory is the source of truth for who has access.
- Rate limit the login. An internal tool with an unthrottled login is a credential-stuffing target like any other.
- Enforce permissions at the data layer, not in the interface. The API is reachable regardless of what the page renders.
- Log who saw what, not just who changed what, if the data is sensitive.
The honest question: build or buy?
We answer this during the audit, and often the answer is buy - a commercial platform is a great deal of software for the money, and if your tool is mostly forms over a database you will spend more maintaining a custom one than licensing theirs.
| Your tool is… | Probably | Because |
|---|---|---|
| CRUD over a database, used by staff | Buy a platform | You are rebuilding a product that already exists and is cheaper. |
| Encoding real business logic nobody else has | Build | The logic is the value and no platform models it. |
| Customer-facing at any point | Build | Platform pricing and branding both break at that boundary. |
| Growing a new integration every month | Build | Per-connector pricing outruns the value quickly. |
| Already built and working | Harden it | A rewrite to a platform costs more than fixing what you have. |
The order to fix things in
- Audit logging on the tables that carry money, permissions and customer data. First, because it is the only one you cannot backfill.
- Ownership transfer: accounts, domains, repositories and credentials into the company's name, written down.
- Point-in-time recovery on, and a restore actually performed so the recovery time is a number.
- The role model, enforced at the data layer, with tests that assert one role cannot reach another's records.
- Single sign-on, so leaving the company is what removes access.
- Indexes and pagination on the views that have quietly got slow.
Two to five weeks to make a typical internal tool production ready, and the first two items are days. It is unglamorous work, and it is the difference between a tool the business relies on and a tool the business is exposed to.
Written by Kato Chojiro
Takes AI-built MVPs to production: security, data, and the infrastructure underneath.
Connect on LinkedIn