Failure-mode guide
Someone on your team built a tool with AI, and it mostly works: a cost controller at one company built his report from a spreadsheet he uploaded into an AI tool, and the report worked. The building does not stop, and it should not. The seven entries below are the predictable places it turns into a problem, each with a tell you can read and a move you can make.
The seven entries
The tool checks its own work
- What it looks like
- Each fix breaks something else, and the output can look right while the number is wrong.
- The tell
- Five rounds of paste-the-error-back, and the output keeps getting worse.
- What to do at the edge
- Cross-check against an analysis you trust; the model wrote its own tests. When fixes diverge, restart narrower.
- Who holds it
- The person who knows the work.
The app nobody maintains
- What it looks like
- Google changed something, the ERP updated, and the builder is now maintaining instead of building.
- The tell
- The tool that was supposed to save time has a queue.
- What to do at the edge
- Every integration is a maintenance subscription; when everyone depends on the app, that is the handoff.
- Who holds it
- The builder, then whoever owns maintained software.
The credentials in the config file
- What it looks like
- It runs on a laptop with credentials in a config file, needing servers and environments it does not have.
- The tell
- Someone says, "just give the model the production credentials."
- What to do at the edge
- Nothing touches company data without the four controls: verified read-only, audit log, rollback, named owner.
- Who holds it
- IT, from the start.
The one-person tool
- What it looks like
- Logins, roles, permissions, and concurrent use are a different category of software than the prototype.
- The tell
- The second person asks for an account.
- What to do at the edge
- A working prototype and a clear spec at the line is a real result; stopping there is a success.
- Who holds it
- The department head who wants it team-wide, with IT.
The question from compliance
- What it looks like
- The tool touches financial reporting, quality systems, or patient data, where informal prototypes cannot live.
- The tell
- Someone from compliance asks who validated it.
- What to do at the edge
- Regulated surfaces need validated processes; the prototype becomes the specification for the compliant version.
- Who holds it
- Compliance and the process owner.
The person who leaves
- What it looks like
- Your best builder leaves, and nobody else can pick up what they built.
- The tell
- The knowledge lives in one person's chats, prompts, and head.
- What to do at the edge
- Reusable instruction sets, written specs, and a team that shares the skill survive the person.
- Who holds it
- The builder's manager, while the person is still there.
The 70 percent tool
The six failure modes have tells you catch early; this one works differently. The tool keeps working, and what fails is the company's ability to evaluate it.
- What it looks like
- The builder loves the mostly-working tool, and every one-off feature makes it harder to replace.
- The tell
- Would a new hire, no stake in having built it, choose this tool?
- What to do at the edge
- Name it in the room early; prototypes are the basis for a real build decision.
- Who holds it
- The builder and whoever decides what gets built for real.
What they share
Each entry ends at a handoff point: the moment the prototype has finished its job and the next step is a product decision. Stopping there is a success.
If you want to see the ground underneath before anyone builds, run the build-over inventory.
Where this comes from
These failure modes come from delivery work and live conversations with buyers through 2026. We review the list on a cycle and add an entry when the field shows us one we missed. Last reviewed September 2026.
Read the tells against your building
A Working Session reads these tells against what your people have actually built, and you leave with a verdict: build, buy, do it yourself, or not yet.
Book a Working Session