The SaaSpocalypse, vibe coding, and what a Coast business should make of it

In February 2026, roughly $285 billion was wiped from the valuations of SaaS companies in a 48-hour window. The commentariat called it the SaaSpocalypse. The trigger was a simple realisation by investors: if anyone can now build custom software by typing what they want in plain English, the assumption that every business has to rent rigid, off-the-shelf SaaS tools at $50 to $200 per seat per month no longer holds the same way.

The phrase driving the conversation is vibe coding. It was coined by Andrej Karpathy, a co-founder of OpenAI, to describe the practice of building software by describing the outcome to an AI and letting it write the code. Eighteen months later, vibe coding is a $4.7 billion market, an estimated 41 percent of all new code is AI-generated, and 63 percent of vibe coding users have no formal development background.

The cost of building software has fallen sharply. The standards for governing it have to rise to meet that shift. For a Coast business, that is both an opportunity and a quiet new responsibility.

What vibe coding actually is

In practical terms, vibe coding lets a non-developer describe what they need ("a portal where my clients can book in jobs and upload photos") and watch a working prototype appear in front of them within an hour. Platforms like Lovable, Bolt, Cursor and Replit have made this accessible to anyone who can write a clear sentence.

The capability is real. The Coastie AI website you are reading was built in Lovable. The internal tools we use to run client work were built the same way. I hold Diamond-tier status with Lovable, which is the highest practitioner credential the platform issues, and I work inside this layer daily. The distance between an idea and something usable has collapsed.

The capability also has limits. A prototype shipped without review, without security consideration, without a plan for what happens when something breaks, is a prototype. With the right discipline, the same tool produces assets a small business can rely on. The discipline around the tool decides whether the output is fit to put in front of paying customers.

Why a human in the loop is not optional

The intuition that AI removes human error is reasonable, and it is wrong in a specific way.

In December 2025, the code review platform CodeRabbit analysed 470 real-world pull requests across open-source projects. AI-generated code contained roughly 1.7 times more issues on average than human-written code. Logic errors rose by 75 percent. Security vulnerabilities increased by 1.5 to 2 times, with the most common web-app flaw appearing 2.74 times more often.

The finding is not that AI-generated code is bad. It is that AI-generated code without review is measurably more defect-prone than human-written code with review. That distinction is the whole governance point.

A short example. In January 2026, an AI-built social app called Moltbook launched after its founder publicly stated he "didn't write one line of code." Three days later, a security firm discovered the app had exposed 1.5 million API keys, 35,000 email addresses, and thousands of private messages. The code was not the failure. The configuration of the database behind it was. Nobody with security awareness reviewed what the model had built before it went live.

What this looks like inside a Coast small business

A quieter version of the same story is now happening inside organisations. Individual staff are using AI to build small tools their owners have not yet seen, mapped, or governed.

A bookkeeper builds a spreadsheet automation in an afternoon. A practice manager spins up a client-intake form over the weekend. A trade business connects a model to its quoting workflow and quietly starts running real estimates through it. The capability is welcome. The governance position is the live question.

A concrete example. A Coast veterinary clinic could, today, build a booking-and-reminder app using Lovable and a free database in a Saturday afternoon. The app would work. It would store client details, animal records, billing notes and possibly photos of medical conditions. It would also sit outside the practice's IT environment, outside its privacy policy, outside any backup procedure, and outside any incident-response plan. The person who built it is not behaving recklessly. They are solving a real problem with the tools now available to them. The same app, built with the same tools but inside a sanctioned process, becomes a useful operational asset rather than a quiet exposure.

The Australian deadline

This conversation has a date attached to it.

On 10 December 2026, a new part of the Privacy Act takes effect. From that day, every organisation covered by the Australian Privacy Principles has to update its privacy policy to explain where it uses computers to make decisions about people. The obligation covers every Commonwealth agency and every private business with annual turnover above AUD $3 million. Smaller operators are exempt today, although the government has signalled that exemption will narrow over time.

The obligation covers two situations. A decision made entirely by a computer program with no person involved. And a decision where the computer program does something that directly shapes the outcome, even if a person signs off at the end. If a decision could reasonably affect a person's rights or interests and a computer program played either role, the privacy policy has to say so.

The part that has caught most boards out is the reach. The obligation applies to every automated tool already in use, including the ones built before the law was written. A rostering tool put together by an operations manager last winter is in scope. A client triage form built in Lovable over a weekend is in scope. An HR shortlisting model running quietly in the background is in scope. A chatbot answering customer queries without a person reviewing the reply is in scope. The privacy policy on the website has to describe all of it.

This is where the vibe coding story and the privacy law story meet. A business that has not mapped the AI tools sitting inside its operations cannot write an accurate privacy policy by December. The work to be ready for that date is not a legal drafting exercise. It is a mapping exercise. Identify the tools in use. Note which ones touch personal information. Note which ones shape decisions. Write the privacy policy from that documented picture rather than from a guess.

Where the line sits for a Coast business

The line sits between what a capable person can build and what an operation should depend on.

A capable Coast business owner with a vibe coding tool can build a prototype this weekend. With the right discipline, they can build a production tool worth keeping. Without it, they can build something that looks polished enough to be promoted into operations before anyone notices. The speed of creation has changed. The standards for fitness, security and accountability have not.

The businesses that read the SaaSpocalypse correctly will not pivot to replacing their core systems with weekend builds. They will look at the underlying signal. Software is becoming cheaper to build, which means the volume of software being built inside the business is rising, often without the owner knowing. The governance task is to map that quietly emerging footprint and bring it under structured oversight before it becomes a liability.

If you would like a hand mapping the AI tools already running inside your Coast business and getting your privacy policy honest about them before December, our Blueprint is the right shape for the work. The Find your AI quick wins email is the right next step.

---

This article adapts an earlier piece originally published under Kristina's international maritime brand, Southern Sky AI, for Central Coast businesses.