Your homemade tool has a second user. Someone else now depends on it.

Imagine someone in sales building a small tool that turns incoming requests into draft quotes. She knows its limitations. When it gets a product wrong, she recognises the mistake and fixes it.

A colleague asks for access. Soon he uses it to prepare the quotes he sends each morning. He has never seen the mistake she learned to catch.

The tool has acquired a dependency before anyone has formally launched it.

That second user is a useful trigger for a short operational review. It is a house rule you can adopt, not a legal threshold or a guarantee that single-user tools are safe. A prototype handling sensitive data or changing customer records needs attention from its first use.

Keep the initiative, examine the dependency

The person who built the tool has found a job worth improving. Start by asking which part of the work it removes and what people would do if it stopped tomorrow.

A tool that reformats a paragraph and leaves the original intact needs different controls from one that writes prices into your quoting system. Look at the data it reads and the actions it can take. Include the steps outside the screen: copying the result into an email may turn a draft into a customer commitment.

Write down the current users and the work they rely on. Ask them separately about the tool's limits. If only the builder can explain when to distrust the output, that knowledge needs to travel with access.

Make one shared record

Before extending use, give the tool a short operating record that another person can find. It should answer these questions:

• Who is responsible for it, and who covers their absence?
• Which account owns the application and pays for its services?
• What data can it read, retain or change, and who has authorised that access?
• Which outputs need checking before use?
• How can someone stop it and return to the previous way of working?
• Where are the source, configuration and recovery instructions kept?

A personal account creates an immediate question about continuity. Moving the application to an organisation-controlled account may help, but the move itself needs checking. Permissions and integrations can behave differently after a transfer.

Record the limits plainly. “Drafts quotes for these product families; all prices checked before sending” is more useful than “AI sales assistant”.

Try the recovery before anyone needs it

Choose a harmless test case. Let someone other than the builder use the instructions, find the right version and recover from a simulated failure in a safe environment.

For the quoting tool, include an unknown product code and an unavailable price. The expected behaviour should be explicit. A missing price should stop the quote or request a check, rather than produce a plausible amount.

Also test access removal. A departing colleague should lose access without disabling the whole team's tool. If that cannot happen, the account arrangement needs work.

Keep a record of the tested version. When the builder changes the prompt or a connected service, rerun the relevant cases before sharing the update. Otherwise, yesterday's test says little about today's output.

Give the builder somewhere to take it

An approval process that offers no practical help leaves the same employee doing development and support alongside her ordinary job.

Choose a route that matches the tool's importance. Keep a low-risk experiment small. Support a useful shared tool with an owner and time for maintenance. If the work belongs in an existing application, plan the move and preserve the useful parts of the prototype.

Solve IT can help turn an internal experiment into an agreed implementation: connecting the systems it needs, testing the actual work and defining operation and handover. The scope starts with the dependency you have, rather than a demand to rebuild everything.

Request a Strategy Session with the builder and one colleague who uses the tool. Bring the quote that required a manual correction.