You decided to build one internal tool. Good. Most of what you will read online stops at the same place: the demo, the launch, the applause. Here is the part that advice leaves out. Building the tool is the easy part. Owning it is the job, and the job is permanent.
Every tool you ship starts a second project that never ends: keeping it alive, correct, and safe. The failure modes are known, boring, and predictable. The maintenance cliff. The verification gap. Shadow IT. Data gravity. Liability. None of them is a reason not to build. Each has one rule that contains it, and two of those rules, set on day one, do most of the work. You will meet all five. Here they are, with the rule that contains each.
The maintenance cliff: you own the 2 a.m. version
The day you stopped paying a vendor, you became the vendor. The monthly subscription you canceled included more than software. It included somebody's pager rotation, somebody's patching calendar, and somebody whose job was on the line if the thing broke. All of that now points at you.
So when the report stops reconciling, or the approval flow silently drops a step, or the AI tool you built on updates its model and the output changes shape, there is no support ticket and no account manager. There is you at 2 a.m., or your ops person resenting you at 8 a.m.
The rule that contains this: only build what you are willing to own, and own it on a calendar. Name a human owner for every tool. Put a recurring hour on their calendar every month, no exceptions. If nobody is willing to own it next quarter, do not build it to last. Build the throwaway version, use it for the quarter, and discard it without ceremony. Disposable software is not a failure of discipline. It is the honest way most internal tools should live, because most of them are answers to a question that will change.
The verification gap: name the reviewer
You can generate code faster than any human can review it. Generation was never the bottleneck. Correctness was, and AI widened the gap, because the output arrives confident and plausible, and the error hides in the exception path: the edge case, the February entry that does not quite fit the rule.
A good review is not a skim. It is running the tool against a case you already know the answer to, then a case you do not. It is reading what the tool did with last quarter's data before you trust it with next quarter's.
The rule that contains this: who reviews the output. Not the developer. The person who owns the business rule. If the tool computes commissions, the sales manager signs every change. If it prices jobs, the estimator signs. A change that touches customers or money does not ship without that signature, and the signature leaves a trail.
Shadow IT at industrial scale: build in the open
Your one tool is a template. It works, word gets around, and by spring three other teams have built three more versions, each forked from somebody's memory of yours, each with its own bugs and its own private login. Next year you have an estate nobody mapped. The C-suite knows this fear by name. When Retool shipped an enterprise-governance product in June, its hook was blunt: AI-assisted "vibe coding" by non-developers now tops the list of C-suite concerns. You cannot secure what you don't know exists.
The rule that contains this: make visibility cheaper than secrecy. The first build goes through a review, not an obstacle course. Show it to IT. Put it on the map. Give it a named owner. If your review process takes a month, you have taught everyone to skip it, and the estate goes dark again, only now with a better reason. You cannot stop the building. You can only decide whether you know about it.
Data gravity: decide where the data lives
The tool is the easy part. The plumbing is where the months go: permissions, sync, reconciliation, and the question of whose copy of the truth is the truth. If the tool keeps its own private copy of customer or order data, you have bought a second system of record and a lifetime of keeping two versions of reality in agreement. The divergence is where the quiet errors live: the order that shows up in the tool but not in the ERP, the customer whose credit line the tool thinks is current.
The rule that contains this: where the data lives. The system of record stays the system of record. The ERP, the CRM, and the ledger keep the data of record and the audit trail. Tools read and write through them, or through a controlled copy with a named reconciler and a date on the calendar. Decide this before the first screen is built. It is miserable to retrofit, and the retrofit is usually an incident.
Liability: do not build what you cannot defend
When you bought software, accountability came in the box: a vendor to sue, an SLA, a SOC 2 report to hand the customer whose security questionnaire asks who is responsible. Build it yourself, and that answer becomes a person, eventually you, and the trail behind that person had better exist.
The rule that contains this: build only what you can defend in writing. For regulated industries this is decisive, and it is the honest answer to what you should keep buying. Nobody is rebuilding their general ledger, and nobody should. Payroll, compliance, infrastructure, and anything where the right answer to "who is accountable" has to be a contract: keep the vendor and keep paying. The ground that is yours to build on is the workflow layer: the forms, lists, reports, and approval flows that sit around the system of record.
The two rules
Set both before anything ships. Rule one: where the data lives. Rule two: who reviews the output. Write them on one page, name the data store and the reviewer, and put the page where everyone can see it. Set them on day one, or you will set them after an incident, and that meeting costs more than the tool did.
Everything else is schedule. A monthly review where the data reconciles, the reviewer signs, and the tool still earns its keep. A kill question at the same meeting: is anyone still using this? Retire what nobody uses, without ceremony. Owning software is mostly a calendar with names on it.
What you actually decided
The day you decided to build, you decided to own. That is not a warning against building. It is the price of admission, and it is payable. The same collapse in cost that made the tool buildable made the ownership burden survivable for a company your size. Tools are cheap now. Discipline is the product. Build the tool, then build the second thing, the discipline to own it, and you will have software as specific to your operation as anything a company ten times your size runs.
If you built it and it broke, or you built it and it works, I would like to hear about it: [email protected].