Somewhere in your company this week, a salesperson asked an assistant to build a commission calculator. It worked. The numbers came out right, the edge case for split deals was handled, and the whole thing took less time than the meeting where the problem was raised.

Then the file went into a Downloads folder and stayed there.

This happens constantly now, and it is not a story about bad code. The code is usually fine. It is a story about everything that sits between working code and a tool your team uses on a Tuesday, which turns out to be a much longer distance than the writing.

The four minutes and the four weeks

Ask an accountant what they want and you get something specific: a script that reads two exports and tells you which transactions do not match. Ask an AI to write it and you get a script that reads two exports and tells you which transactions do not match. That part is genuinely solved.

Here is what is between that script and month-end close:

You need somewhere to run it. Not your laptop, because the close does not stop when you are on a plane. Somewhere that stays up.

You need your colleague to be able to open it. Which means a URL, which means a server that stays awake and a certificate so their browser does not warn them off. Then someone has to decide who else gets that link.

You need it to still work in March. Dependencies drift, an API changes, and the person who needs it fixed is the accountant who asked for it, looking at a stack trace.

And you need someone to say yes. In most companies, running unreviewed code that touches financial data is a ticket with IT, and the ticket waits behind everything filed before it.

None of these are coding problems. They are all operations problems, and operations is exactly the skill the AI did not hand you along with the script.

What people are actually building

This is not hypothetical. The examples are already documented in the trade press, and they are not moonshots. The Journal of Accountancy collected a set of them in June 2025.

At the Capital Area Food Bank, a controller built himself a workflow that scans, summarizes, and responds to incoming mail, because processing it by hand was eating the team’s week. It is an unglamorous problem and a real one.

At an advisory firm in Memphis, a finance leader built a bot that drafts technical accounting memos against the firm’s own back catalogue. He puts it at going from a four-hour task to a 30-minute one, and that 30 minutes still includes careful human review.

In sales, the pattern is the same shape. Lead scoring that reflects how your team actually qualifies, rather than how the CRM vendor thinks you should. Business cards photographed at a conference and turned into CRM records with follow-ups attached. Call transcripts read for the moments where the script fell apart.

Notice what these have in common. They are all small. They all encode something specific about how one team works, which is exactly why no vendor sells them. And every one of them is worth more running than sitting in a folder.

The successful ones have something in common too

Look at which of these tools survive contact with a real week, and a pattern shows up quickly.

The ones that live are the ones that never needed a terminal. A Power Automate flow lives in the tenant your company already pays for. A custom GPT lives at a URL someone can bookmark. A Zapier automation runs whether or not anyone’s laptop is open.

The ones that die are the raw scripts. Not because they are worse, but because a Python file is not a place. It is a set of instructions for reaching a place, and the instructions assume you already have the right Python version installed and know how to keep the process running after you close the laptop.

This produces a bad outcome that nobody chose. The most flexible tools, the ones that could do anything because they are just code, are the ones least likely to get used. Capability and survivability run in opposite directions, and the deciding factor has nothing to do with the work.

The security answer is not “no”, it is “who”

There is a real objection buried here, and it deserves better than a shrug.

Code an AI wrote, that nobody reviewed, that reads your general ledger, is a genuinely reasonable thing for a security team to be nervous about. And it is already happening at scale: Microsoft and LinkedIn’s 2024 survey of 31,000 workers found that 78% of people using AI at work were bringing their own tools to do it. IBM’s 2025 breach report puts a price on where that goes wrong, adding $670,000 to the average cost of a breach where shadow AI use was high.

But look at what “no” actually produces. It does not produce zero tools. It produces tools that run on someone’s laptop, with a copy of the data sitting on that laptop and nobody in IT aware the tool exists at all. The risk did not go away. It moved somewhere nobody can see it.

The useful question is not whether people should run software nobody reviewed. They already do. The question is whether that software runs somewhere isolated, with sign-in in front of it and a record of who opened it, or in a Downloads folder.

What has to be true

If small software is going to survive the last mile, a few things have to stop being the user’s problem.

Getting it running has to not require describing it. Everything needed to run a piece of software is already in the source. Making a non-engineer restate that as a Dockerfile is asking them to translate into a language that exists only to serve the platform.

Sign-in has to be there before anyone asks. An internal tool that anyone with the link can open is not really an internal tool. Work email should be the door.

Sitting idle has to be cheap. Most small software is used on the first Monday of the month and ignored for the other twenty-nine days. If it costs the same to sit still as to run, someone eventually reads the bill and deletes a tool that earns its keep one day a month.

And it has to be recoverable by the person who owns it. When something breaks in March, the fix cannot require the skill the person did not have in January.

That last one is the interesting part, because it is now tractable in a way it was not two years ago. The same assistant that wrote the tool can read the error and repair it, provided it can see the logs. The loop that used to need an engineer can close without one.

Where this leaves you

If you have a folder like this, you already know the feeling. The tool works. It solved the actual problem. And it is stuck, for reasons that have nothing to do with whether it was any good.

That gap is the thing Sploot is being built to close: you hand over the folder, and you get back a link your team can open with their work email. It is in private beta and not open yet, so this is not an invitation to go try it today.

But the gap is worth naming either way. The hard part of small software stopped being the writing. Everyone is still tooled up for a problem that got solved.

Your assistant wrote the tool. Now what?