AI tools such as Lovable and Figma Make are enabling non-developers to build working software, and that work is moving quickly past experimentation and out of the sandbox into production, where it now solves live business problems. Use cases that used to take months to specify and build are now turning up across the business: finance teams automate reconciliation workflows, HR builds onboarding portals, and operations wires together dashboards. The list goes on. 

The barrier to creating functional software has collapsed, and for a growing number of your colleagues, ‘vibe coding’ is simply something done as an aside on any given Tuesday afternoon. 

Embrace it, but curate it 

Vibe-coding tools are the latest route to what’s usually called citizen development: employees outside IT building software for their own work. That development is worth welcoming, because the people closest to a workflow know best what it needs. 

Done well, it can bring real upside: prototypes arrive far faster, and ideas from the people closest to the work can feed a steady pipeline of improvements. That freedom needs curating, because whether something can be built is now the easy part. The harder questions are whether it’s worth building, and whether it will hold up once the business depends on it. 

The ‘almost done’ app 

Here is a pattern we see again and again: someone has vibe-coded a solution. It looks right, it clicks right, and it solves a hands-on problem. “It just needs a quick check before it goes into production,” they say, and the app lands on a developer’s desk. 

The business believes the app is 90% done. But the developer sees it very differently: the part you can see on screen may be finished, but the work that makes software dependable hasn’t even started. As a rule of thumb, based on our experience, the app may be closer to 10% than 90% done. 

That, however, doesn’t make the prototype worthless. A working prototype is a valuable, living specification of what the business needs, but it should be regarded as a starting point and not the finish line. 

And this is the core of the problem: quality cannot be inspected into software at the end. A ‘quick check’ only works if quality has been built in along the way. Otherwise, the check turns into a rebuild. Asking a developer to approve an app at the end is the most expensive moment to find out what’s missing. 

If quality goes in… 

Vibe-coding tools are a genuine step forward, and what they produce is still software. We’ve been building software for a long time, so when employees outside IT start building, there’s plenty of experience to draw on, and the cheapest place to use it is at the first prompt. 

FURPS is a simple, long-established model from software engineering. Its five areas cover what decides whether a solution works and holds up over time. Given the current threat landscape, we have added a sixth area, a second S, for Security, because it matters so much for apps built without anyone reading the code. Each area comes with questions worth asking before anyone starts building, so that the answers can go into the brief.

Make the safe way the easy way  

So, should everyone build software? Yes, as long as quality is part of the brief from the first prompt. The next question is how to let people build without the organisation losing control, while still gaining the value that made it worth building.

It starts with a shift in thinking: our aim is to make the safe way the easy way. To do that, you need to create the foundation, with the proper fencing and tools already in place, so employees can be creative within predefined boundaries. This could include:

• A governance structure to keep track of which applications exist, who owns them, and what data and systems they have access to. 
• Communities and training on innovation and UX processes, to help people identify valuable ideas and work towards viable solutions. 
• Tools such as automatic deployment, security scans, and regression testing, so the business can support itself, own the product, and solve issues as they arise. 
• A clear strategy and workflow for selecting and upgrading the valuable products that need to be scaled further into the business. 
• Self-service templates that bundle all of this.

A good platform removes whole categories of errors, especially around security, hosting, and reliability. But it can’t decide what the app should do, or whether it does it correctly. That part stays with the business, which is why quality belongs in the first prompt and not in the final review. And if a developer is going to be involved, involve them at the start, as a sparring partner, and not at the end as the one who has to approve. 

So how do you keep quality and control with vibe coding? By making quality part of the brief from day one, and by building a foundation in the organisation that makes the safe way the easy way.