Internal tools

Because a 40-tab spreadsheet or a script one person maintains is rarely a large enough problem to justify pulling a full engineering team off customer-facing work, even though the manual cost to the business keeps recurring every week. AI-written code changes that calculation: the cost of building the unglamorous internal tool properly drops far enough that it can now win priority over other work on the roadmap.

Because the process document describes how the workflow is supposed to work, and the actual workflow usually has a workaround, an exception, or a manual fix that nobody wrote down. Watching it run shows the real steps a new tool has to replace, including the ones the person doing the job stopped mentioning because they assume everyone already knows about them.

We build the smallest thing that removes the manual step, not the largest thing that could plausibly replace the whole spreadsheet or script. That keeps the first version fast to release and easy for the person using it daily to evaluate, since they are judging one specific problem rather than a broad reimplementation of everything the old tool did.

Changes happen the same week the tool is given to the people doing that job. Internal tools have a fixed group of users who must use them: the same handful of people use the tool daily and have no reason to hide what is wrong with it, so feedback is fast and specific rather than the delayed, filtered feedback a customer-facing product gets.

Two to five weeks per tool is the range we scope to, not a measured average, since this is engagement pattern guidance rather than a record of past projects. Consolidating several internal tools into one system takes longer and is scoped separately, since combining workflows raises different questions than replacing a single spreadsheet.

Often yes, because the calculation that used to rule it out was the cost of a full build against a small user count. With that cost down, the question becomes whether the manual step those three or four people repeat is expensive enough in time or errors to be worth removing, which a five-minute conversation with them usually answers.

It can, and an outdated admin panel is one of the specific examples this pattern covers, alongside spreadsheets and single-owner scripts. The same approach applies: find out what the panel is actually used for by watching it in use, then build the smallest replacement that removes the parts that are actively causing problems.

It keeps changing based on what the people using it say, in the same week they say it, rather than sitting fixed until a future project revisits it. Because the build cost stayed low, refining an internal tool after launch is a normal, ongoing adjustment rather than a separate project that has to compete for budget again.