Give your citizen developers a road
I created sprawl.
Back in the '90s I was a software developer. I built stuff fast, everywhere. That is what I did, and three years later I looked at it and thought, this is a disaster. The mess was mine. I got there because I kept building and I didn't leave a path for any of it.
Today anyone can build an app in an afternoon. Lovable, Claude, and V0 are the new spreadsheets. I love that, seriously. People who never would have written software can now stand up something useful in a few hours, and if you care about solving real problems at work, that is a gift.
I'll be honest. I love these tools, I use them, and I want more people building, not fewer. The '90s version of me would have been first in line. That is exactly why I care about the path. The person who loves to build is often the person who will create sprawl if there is no road.
But I've seen this movie before. When the tools get this easy, the same pattern shows up. A burst of useful little apps, and then a pile of questions that nobody wanted to ask on day one. Who has a real login? How does a new version get released? What testing happened along the way? That pile is the disaster I already lived through, just with new tools.
The instinct for a lot of leaders is to ban it. Lock the tools down, tell people to stop building, and wait for a formal team to do it the approved way. I get why that feels safer. I just don't think it works. Banning it doesn't stop the building. It pushes it out of sight, into personal accounts and random sites you will not see until something breaks.
The answer is a path, from prototype, to pilot, to production. You can also think of it as try it, prove it, run it. Same idea. Let people build, and give them a road so the good stuff can make it into the business without turning into a mess three years later.
In the prototype stage, you want people to try things. Messy is fine here. Someone close to the work has a problem, they stand up a small app, and they find out if the idea even works. This is not the time for a heavy process. If you put one on them too early, they will stop trying, or they will try in a place you can't see. The point of this stage is to learn, not to get it perfect.
Then you get to the pilot. This is where you prove it. It needs a real login, a small group using it on real work, and enough testing to know it holds up. Someone has to be on the hook to say whether it is worth taking further. A lot of ideas should stop here, and that is all right. It means you learned without turning a trial into something the whole company now depends on.
Then production, the run-it stage. Now it needs a real release process, real testing along the way, and a home in the business. Someone owns it. You know how it gets updated, and you know who can see what. It is no longer a side project that happens to be sitting where staff depend on it.
The tools changed, but the principles didn't. I still want the citizen developers to build. I want the person closest to the work to be able to try something in an afternoon and show it to the team. That is how you find ideas you would never have written into a long plan. I just want a road under them, so the thing that works can move from a prototype into something you can support, secure, and stand behind.
That is a big part of how we think about purpose-built apps and AI enablement. Help people use these tools on real work, and when something is worth keeping, give it a proper path in, with the kind of security you would want on anything the business actually runs on.
If I were sitting with you, I wouldn't start with a list of tools to ban. I'd start with what your people have already built, and whether those things have a road to travel or if they are already starting to sprawl. What has your team built in the last few months, and does it have a path, or is it sitting in that messy middle with no owner?
