The riskiest software at your company may have been built last month by someone with an AI subscription and a free afternoon.
Build versus buy used to be a budget question. Building took developers, and developers took time, so most companies bought. That math changed. A smart analyst can now produce working software in days, and she doesn’t need IT’s permission or a vendor contract to do it.
The cost of building dropped, but the risk model didn’t move with it.
The analyst who did two jobs
One company I know of had an analyst who built a set of agents that did the work of two people. They worked, and leadership was thrilled. Then she left for another job.
Those agents ran using her credentials. That leaves the company with two bad choices: disable her account the way offboarding says you must and the agents stop, or leave it active and a former employee’s login quietly runs business processes. Nobody planned for either outcome, because nobody had thought of the agents as systems. They were just her work.
The ticketing platform that works fine
Another team built its own IT ticketing platform. It does what they need, and it has for a while. But nobody has asked what happens when it stops. Who understands how it’s put together? Where does the data live? Who gets the call at 7 p.m. on a Friday?
“It works fine” is true until the day it isn’t, and by then the platform has become something the business can’t run without.
What you used to get for free
When you buy software, you inherit a lot of things you never really thought of as features: a support line, a patch cycle, a contract that says what happens to your data, and usually a security review you can point to. A vendor going away is a risk, but it’s a known one with a process attached.
Software built in-house last month comes with none of that unless someone builds it in. The tool is cheap. The ownership is the part that costs something, and it’s the part nobody budgeted for.
Five questions to ask about anything someone built
- Whose credentials does it run on? They should belong to the company, as a service account with an owner, and never to one employee’s login.
- Who owns it? A named person plus a backup, written down somewhere.
- If it stopped tonight, what breaks, and who would notice first?
- Where does it send and store data, and does your vendor and system inventory know it exists?
- Does offboarding check for it? When someone leaves, the checklist should ask what they built and what runs under their name.
If you’re a bank, I’d expect an examiner asking about the systems that touch customer data to care very little whether you bought them or an employee built them. An internal tool that handles that data is in scope either way.
None of this is an argument against building. Build the thing. Just don’t let it become the only copy of how your business runs, held together by one person’s login.
If you want help finding out what’s already running at your company, book a call: https://cal.com/vaughn-cyber-group
