Every small business has a spreadsheet that should not be a spreadsheet.
It started as a simple list. Then it grew a second tab, then a column of colour-coded statuses that only one person understands, then a formula somebody wrote in 2023 that nobody dares touch. It is now load-bearing. It breaks when two people open it at once. Everyone agrees it should be a proper little tool, and nobody has ever built one, because a developer would quote four thousand euros for something this small and be entirely right to.
That gap, between a problem too small to pay for and too annoying to ignore, is where vibe coding lives. It is the first thing in a long while that genuinely addresses it, and it is worth understanding clearly rather than through either the hype or the backlash.
What vibe coding actually is
The term was coined by Andrej Karpathy, a co-founder of OpenAI, in February 2025. It describes writing software by describing what you want in ordinary language and letting AI produce the actual code, then refining it by giving feedback rather than by editing the code yourself.
It has moved well past novelty. Collins Dictionary named it Word of the Year for 2025, and MIT listed it as a Breakthrough Technology for 2026. Those are not technical endorsements so much as evidence that the practice became widespread enough to need a name, which is usually the more meaningful signal.
In practice you type something like a request for a customer dashboard with a login page and a chart showing monthly revenue, and you get back a working application. Then you look at it, notice the chart should be by week rather than month, say so, and get a revised version. The loop is conversational rather than technical, which is precisely why around 63% of people using these tools are not developers. They are marketers, teachers, freelancers, designers, and business owners solving their own problems.
The tools sit in two rough camps and the distinction matters when choosing one. Lovable and Bolt lean toward rapid prototypes. Zite, Base44, and FlutterFlow position themselves for production applications with stronger security postures. Replit sits across both. Pricing generally runs from around $19 to $50 a month, which is the number that makes the whole thing viable for problems that were never worth a development budget.
Why it stopped being a toy
Generating plausible-looking code has been possible for a while. What changed is the surrounding machinery, and that is the part that determines whether a non-developer ends up with something that works or something that looks like it should.
The first change is that these tools now run the code they write. A model that generates a program and hands it to you has given a non-technical person a file they cannot evaluate. A tool that generates the program, runs it, sees the error, and fixes the error has closed the loop that previously required a human who could read a stack trace. That is the difference between a code generator and something a business owner can actually use.
The second is deployment. Building an application was never the hard part for most people; getting it running somewhere other people could reach, with a database behind it and a login in front of it, was. Current tools handle hosting, storage, and authentication as defaults rather than as three separate projects you discover afterwards. The gap between it works on my screen and other people are using it has narrowed from weeks to an afternoon.
The third is that the models simply got better at the specific thing this requires, which is holding a whole small application in mind at once and making a change in one place without quietly breaking another. That was the failure mode that made early attempts frustrating, and while it has not vanished, it has receded far enough that a modest tool can be built and maintained by someone who cannot read the code.
What a small business should actually build
The instinct is to build the thing you would otherwise buy, and that is the wrong place to start. Do not vibe code your CRM. Products with thousands of customers behind them have absorbed a decade of edge cases you have not thought about, and reproducing that badly costs more than the subscription.
Build the thing that does not exist because it is too specific to be a product. The spreadsheet that should not be a spreadsheet is the canonical example: an internal tracker shaped exactly like your process, with your statuses and your fields, which no vendor would ever build because your process is yours alone. These tools are extremely good at that, and it is genuinely the highest-value category available to a small business.
Simple internal calculators are another strong fit. Quoting tools that encode your specific pricing logic, capacity planners, commission calculators, anything where the rules live in someone's head and get applied inconsistently. Putting those rules into a small tool makes them explicit, which is often more valuable than the time saved, because it surfaces the three cases where two people in your business have been quietly doing it differently.
Customer-facing micro-tools are the third category, and the one with the most upside. A delivery-area checker, a rough quote estimator, a booking form shaped around your actual availability rules. These are small enough to be built in an afternoon and genuinely useful for reducing the volume of repetitive questions arriving in your inbox, which connects directly to the messaging cost problem we covered in the Meta Business Agent pricing change. The cheapest customer question is the one your website already answered.
How this differs from no-code automation
This is worth separating clearly, because the two get conflated and they solve genuinely different problems.
No-code automation, meaning the world of connecting your existing tools so that a form submission creates a record and sends an email, is about wiring together software that already exists. It is what we described in your first AI automation without code, and for most small businesses it remains the higher-return activity, because most problems are integration problems rather than missing-software problems.
Vibe coding is for when the thing you need does not exist in any form. You are not connecting tools, you are creating one. That is a smaller category than it first appears, and the mistake worth avoiding is reaching for it when a simpler answer exists. A great many things that feel like they need custom software need a properly configured off-the-shelf tool and about an hour of thought.
The honest test is whether you can name the product you would buy if it existed. If you can describe it and no vendor sells it, build it. If you find yourself describing something that sounds a lot like an existing product with your logo on it, buy the existing product. That distinction saves more wasted weekends than any technical advice.
Where it breaks, honestly
Security is the serious one and it deserves to be stated plainly rather than softened. A person who cannot read code cannot evaluate whether the code handles data safely, and these tools will happily produce a working application that stores customer information carelessly. The application will function perfectly. That is exactly what makes it dangerous, because nothing signals the problem.
The practical rule that follows is to keep personal data out of anything you vibe code until someone who can read the code has looked at it. Internal trackers holding your own operational data are low risk. A customer-facing form collecting names, addresses, and payment details is a GDPR obligation with your company's name on it, and building that without review is not a shortcut, it is a liability you have not priced. The tools positioned for production, meaning the Zite and Base44 end of the market rather than the prototype end, exist partly because of this and are the right choice when data is involved.
Maintenance is the quieter failure. The application works in March. In September something upstream changes and it stops, and the person who built it cannot debug it because they never could. This is the same pattern as the abandoned spreadsheet formula, just with more surface area. Anything that becomes genuinely load-bearing needs either someone who can maintain it or an honest acceptance that it may need rebuilding rather than repairing.
And there is a scope trap worth naming. These tools make the first version so fast that they invite you to keep going, and the tenth feature is much harder than the first because complexity compounds. The projects that succeed stay deliberately small. The ones that quietly consume three weekends started as an afternoon and kept growing because each addition seemed like ten more minutes.
How to start without wasting a weekend
Pick the spreadsheet. Not the ambitious idea, the annoying one. The thing that already exists in a broken form is the ideal first project because the requirements are already known, the value is already proven, and you will recognise immediately whether the result is better than what you had.
Give yourself a fixed time limit and mean it. Two hours is enough to know whether this works for your problem and your temperament. If you have something usable at the end, that is a genuine result. If you have a half-built thing and rising frustration, stop, because the sunk cost is two hours rather than a weekend and the information you gained is worth having either way.
Keep the first version smaller than you want. Build only the part that replaces what the spreadsheet does today, without the three improvements you have been imagining. Improvements are easy to add to something that works and impossible to add to something you abandoned because it grew too complicated to finish.
The reason any of this matters is not that every business should be building software. It is that the category of problem worth solving just expanded. For years the answer to a small, specific, genuinely annoying operational problem was to live with it, because the cost of fixing it exceeded the cost of enduring it. That calculation has changed, and the spreadsheet nobody dares touch is a reasonable place to find out by how much.