The obvious question is: didn't we already solve this? 

We've had low-code platforms, internal tool builders, no-code app makers for a decade. But look at how those products actually entered a company. IT evaluated them, procured them, provisioned them, and then invited business users in. The platform was the permission. What's happening now is the reverse. The ops lead didn't ask anyone. She opened an agent and built. The tool exists before IT knows it exists, and often before she has thought of it as "software" at all. The last generation of platforms assumed a technical gatekeeper somewhere in the loop. That gatekeeper is gone.

Which puts people in my seat in a genuinely uncomfortable position. As a CTO, my honest instinct when I hear "an employee wrote her own tool that touches inventory data" is not excitement. It's a small heartbeat of dread. Who reviewed it? Where does the data go? What credentials is it holding? The traditional answer is to ban this kind of thing. But banning it now is like banning spreadsheets in 1995. The tools will get built regardless, because they solve real problems the roadmap will never reach. The only real choice is whether they get built in the open, on rails, or in the dark, on laptops.

And "just let people deploy it" hides more problems than people expect.

Identity and permissions are the visible ones. The moment a second person touches a tool, someone has to decide who can log in, who can edit, who can see which rows. Big companies solve this with entire platform teams. Small software has one person who built something on a Saturday.

The one that worries me more is credentials. Agent-built tools work because they connect to real systems, which means somewhere inside them is an API key with real power. I have personally watched a well-meaning employee paste production credentials into a link they genuinely believed was private, because nothing in the interface told them otherwise. That is not carelessness. That is an interface failing a person it was never designed for.

And there's a quieter problem almost nobody discusses: what happens to these tools over time. Small software doesn't get decommissioned, rather it gets orphaned. The person who built it changes teams or leaves the company, and eleven people are now depending on a tool that no one owns, no one can fix, and technically no one knows exists. Big Software has runbooks and on-call rotations. Small software has a laptop and a prayer.

To be clear, none of this is a criticism of AWS or Azure. They were designed to take a business to a billion users, and they are exceptional at that. But most small software will never need to scale. It needs to reach fourteen colleagues on a Tuesday, safely, survive its creator leaving, and keep running quietly for years. That is a completely different job, and today almost nobody is doing it well.

One line from the YC essay stayed with me: small software should be as easy to share with your colleagues as a Google Doc. Notice what that comparison quietly includes. A Google Doc doesn't just share easily. It carries its permissions with it, it lives somewhere the organisation can see, and it survives the author moving on. The sharing is the easy half of that sentence.

On a lighter note, I built a small carpool scheduler for my daughter's school a few weekends back. Six families, weekly rotation, automatic reminders. It took less time than making breakfast for my kids, and no child has waited at the gate in the Delhi heat since.

Sharing it with five more families would have required me to write a backend. Even for me, that felt like too much work for a Sunday. Now imagine the parent who can't.