Should you vibe-code your business systems?

Yes, for most of your stack. Not for the part that matters.

The reporting is now hard to argue with, and it got louder this month.

Fred Turner, CEO of US health insurer Curative, told the 20VC podcast his company cancelled a $600,000-a-year Salesforce contract after building its own CRM in two months with AI. That isn't quite "vibe coding" — building software with an AI assistant and little or no engineering expertise — but it points at the same shift: systems that used to take a year now take weeks. He isn't alone. Per The Information, David Codrea of Greenleaf reckons they saved around US$100,000 leaving Salesforce for an AI-built application; Oplign swapped HubSpot for its own CRM over a weekend. Across the firms surveyed, software spend fell forty to eighty per cent.

I know the shelfware number first-hand, because I signed the invoice. A business where I was directly involved was paying HubSpot over US$5,000 a month — north of US$60,000 a year — billed in US dollars, to HubSpot's Sydney office, carrying the currency spread every month on top. And every line of that was already after their allegedly "very generous" discounts. Dozens of seats across sales and service; some of them logged in about twice a quarter. When Turner said nobody was really using it, I didn't need convincing. The price was never the problem, and a discount was never going to fix it.

The legacy vendor response is predictable: this is dangerous, it won't scale, wait until something breaks. It also has no answer to what's driving the exodus — Salesforce Ben's own 2026 admin survey found 58.6% of administrators saying the platform is getting more complex, and half saying too much is now expected of them. As a blanket statement, I think that "it's dangerous" line is wrong — and wrong in a way that's costing incumbents the argument. But "wrong as a blanket statement" is not the same as "safe." A line runs through the truth here, and almost nobody is drawing it.

The line nobody's drawing

Here's a test you can run on yourself.

Would you let an AI rebuild a simple CRM — somewhere to keep customer details and track deals — over a weekend, and start using it Monday? Probably. If something's wrong, you'll spot it by Tuesday and fix it.

Now: would you let it rebuild the system that works out what you owe your staff and the tax office, and run real pay through it on Monday?

Your CFO just went pale. The reason isn't that payroll is harder — it mostly isn't; it's arithmetic and lookup tables. The reason is the shape of the failure. And if you're thinking Single Touch Payroll covers you: STP reports what you calculated. It doesn't check it. A wrong super rate, a mis-accrued leave balance, a contractor classified as an employee — all of it is lodged with the ATO on time, in full, and wrong.

Vibe coding wins where being wrong is cheap, visible, and reversible. If your pipeline stages are set up wrong, someone notices Monday and changes them. The damage is one afternoon.

Vibe coding loses where being wrong is cheap, invisible, and compounding. Not a dramatic crash — a small error pointed the same way every time: rounding that always goes one direction, the wrong exchange-rate date, a payment quietly attached to the wrong account. Nobody notices. Not Monday, not in March. You notice in year two, when the drift has added up to something you can't wave away, and you can't tell which entries were wrong, because nothing kept a record. An auditor lives with tiny differences all day. What ends careers is the systematic error nobody could see and nobody can now trace.

A CRM that's wrong tells you it's wrong. A ledger that's wrong balances perfectly, right up until it doesn't — and then you're paying a forensic accountant to rebuild eighteen months of history from bank statements.

Notice what most of these cases actually replaced: CRMs, an IT ticketing system, a contract workflow, a reporting dashboard. Places where a mistake surfaces fast — and where these tools are genuinely delivering (Curative got the cost of negotiating a provider contract from $1,500–2,000 down to about $70). Nobody rebuilt their claims ledger or their statutory reporting over a weekend. That's not timidity. It's the same instinct your CFO just had, expressed as a choice about where to point the tools.

The rules a system won't let you break

A serious financial system differs from a CRM in one specific way: it has rules it will not let you break, as opposed to rules someone is supposed to remember.

The difference sounds like hair-splitting until you see it. "Always check the invoice belongs to this customer" is a rule you remember. "The system flatly refuses to show you another customer's invoice, no matter what you do" is a rule it won't let you break. Same intention — completely different outcome when a new hire joins, when it's late on a Friday, or when the thing writing the software is an AI that has never met your customers.

Accountants already understand this, because the profession runs on the most famous example. Double-entry bookkeeping isn't a rule bookkeepers try hard to follow. It's a structure: debits and credits have to match, so an unbalanced mistake announces itself instantly, for free. It won't catch a balanced-but-wrong entry — the right amount in the wrong account, a duplicate that happens to balance, an entry in the wrong period; Enron's books balanced fine. That's what reconciliation is for. But it takes one whole category of silent error and makes it loud, automatically, without anyone having to remember to look.

A financial system needs several rules of that kind. In plain terms, and what happens when each is missing:

Every record belongs to one business, and can't leak to another. In any system serving more than one company, every lookup has to be pinned to the right one. The danger is the direction it fails. Build it so the safe path is automatic and the system quietly returns nothing when something's misconfigured — it fails safe. Leave it to whoever's writing the code to remember, and one forgotten check hands someone another company's data. Same slip, opposite outcome.

Money is never stored as an approximate number. Computers keep everyday numbers as approximations, and some perfectly ordinary decimals have no exact form. You won't spot it in your spreadsheet — the tool quietly rounds the mess out of sight so the total looks clean. That's exactly the danger: the error is still in there, tidied away where you can't see it. Harmless once. Repeated across a year of invoices, through a tax calculation, through a currency conversion, always drifting the same way, it's books wrong by an amount that started too small to notice. (This isn't about decimal places: yen has none, exchange rates want six to eight. It's that money must be handled as exact money, everywhere, so the drift can never start.)

Every invoice number is issued once, and only once. Two people click "create invoice" in the same second. Both get INV-1042. Neither notices, because each only sees their own screen. Now two invoices share a number that's meant to be a unique legal record. Getting this right means the system hands out each number in one locked step. Getting it wrong means asking "what's the highest so far?" and adding one — which is exactly what anyone would write, and looks perfectly correct.

A posted entry is never edited — only reversed. This is the rule that truly earns "errors can't hide." Recording who changed something isn't enough: you can log the change and still let them paint over the old figure, and the history is gone. A proper ledger refuses — you post a correcting entry, and both stay on the record forever. It's also why an audit trail isn't optional: in Australia, keeping records that correctly explain your transactions for the statutory period is the law. The history has to survive, so the system has to make erasing it impossible, not merely frowned upon.

A closed period won't accept new entries. Once you've closed and filed a period, the system refuses a back-dated entry into it — a rule that refuses, rather than a note asking people please not to. Without it, someone drops a stray entry into last quarter and the numbers you already filed quietly stop matching the system.

Here's the heart of it: a weekend build doesn't have rules like these. It has good intentions. Whoever built it meant to pin every lookup to the right company, meant to handle money exactly. The feature added six weeks later — by a different person, or by an AI answering a prompt that never mentioned any of this — doesn't share the intention, and nothing stops it, because the enforcement was never built. It was assumed.

That's what people are reaching for when they say vibe-coded systems "don't scale." It has nothing to do with how many users you have. A rule like these is a promise the whole system keeps, across every change anyone will ever make. A prompt describes one change. The AI answers the question you asked, correctly — and the promise lived in a question nobody asked.

Three ways to be quietly wrong

We build financial software with these tools every day. This isn't a warning from the sidelines; it's what we watch happen.

The payment from the wrong account. A payment gets recorded against the right invoice number — belonging to the wrong company. The code looks correct. It simply doesn't pin the lookup to the right business, because the person building it knew which one they meant, and the AI wrote what was asked. Nothing looks broken. The money left the wrong account. This is the single most common serious flaw in real software, human-built or not, and the one AI copies most faithfully, because the wrong version looks identical to the right one.

The payment that ran twice. A payment notification arrives twice — the bank retried, because your first reply was slow. It gets processed twice. No error, no alert, until someone reconciles the bank feed against a ledger that thinks it collected more than it did. The fix is a simple guard: the same instruction, arriving twice, only counts once. But building that means anticipating a failure that hasn't happened yet — and convincing-looking code handles the normal case beautifully and skips exactly that.

The exchange rate that was almost right. Which rate — the day of the transaction, the day it settled, the end of the period? Before tax or after? Rounded which way? Each has a defensible answer and a wrong one, and the wrong one gives you a number close enough to look fine. On one invoice it's a few cents. Applied the same way across a consolidation, over four quarters, it's a restatement.

This isn't only our experience. A December 2025 review by security firm Tenzai gave five popular AI-coding tools the same three briefs and audited the fifteen resulting builds: sixty-nine security holes, most minor, around half a dozen serious. The pattern matters more than the count: the recurring theme was flaws in business logic — who's allowed to do what, and how data is handled — the kind of mistake a human avoids by understanding how the business is supposed to work, which an AI has no way of knowing unless told.

None of these is bad code. Bad code fails loudly on day one and you fix it before lunch. The danger is code that looks right — it reads well, passes the obvious tests, and balances beautifully for eighteen months. It isn't technical debt either: debt is a mess you can see and budget to tidy up. A wrong exchange rate is a clean, tidy, well-formatted number that happens to be false. Debt has a balance you can look up; this is a liability you find out about from a letter.

And a smarter AI doesn't fix it — it makes it worse, quietly. A better model writes more convincing code, so the errors that slip through are the ones convincing enough to slip through. Even the enthusiasts land here: Tim Combridge, who champions vibe coding, makes the point that code looking like it did the job isn't the same as it having done the job — and that you have to switch from builder to auditor. He's right, and that's the tell: auditing is a control, and controls belong in the system, not in the good intentions of whoever ran the prompt.

The accounting profession worked this out centuries ago, and it never solved it by asking people to be careful. It solved it with controls: separating duties, two signatures on a payment, reconciliation as a structural check. Which is why an AI drafting a journal entry is fine, an AI flagging an odd invoice is useful, and an AI posting either without a human confirming it isn't a feature. It's a missing control.

"Couldn't you just tell the AI the rules?"

This is the first thing every good engineer says, and they're right to. And the good ones don't mean "put it in the prompt" any more. They mean a written, shared rulebook the AI loads every time, plus automated checkpoints that block bad changes before they go live. That's real, it works, and if you're not doing it, start.

But it doesn't close the gap, for a simple reason: the average vibe coder isn't the expert who knows what the rules should be. To get the important parts right, you need someone who understands both the software and the accounting. And some rules can't be known in advance — does GST round per line or on the total? When you split $100 three ways, where does the leftover cent go? Those depend on your jurisdiction, your auditor, your own policy — decisions about your business that nobody has made yet, and that no AI can simply infer.

So to build it with all the necessary rules in place, you have to already know which rules are necessary. And if you know all of that, you're not really vibe coding — you're an expert using AI to work faster, which is an excellent thing to do. The prompt that fixes vibe coding requires exactly the expertise vibe coding was supposed to make unnecessary.

Ask this of every headline, Curative's included. Turner's team scaled a company to seven thousand people and ran national health infrastructure — when they spend two months building a CRM, there are people in the room who know where the traps are. That's not a knock; it's the point. The skill on display is theirs, and it doesn't come free with the tools. A thirty-person firm reading the headline is buying the tools, not the team.

Which tells you where safety has to live: not in a prompt, but in a system that refuses. It won't return the wrong company's data. It won't let money be handled as an approximation. It won't issue the same invoice number twice. It won't accept an entry into a closed period. None of that depends on who wrote the code, or whether the AI was having a good day. It's the payment system that won't submit with one signature, versus the memo asking everyone to please get two.

Build on top of what?

I agree with Bobby Mukherjee at Loka: ripping out enterprise software is a last resort, and the smarter move is usually building on top of it. SaaStr, who have done exactly this, reach it from the other side: the moment you add a second team you need permissions, roles and audit trails, and now you're maintaining a platform, not using one. Buy the platform, they conclude, and build the last mile on top.

Both are right. The question neither asks is the one that matters: on top of what, exactly?

The CRM is the unlikeliest candidate — little more than a list of companies and contacts, records of conversations, and a pipeline. It's the easiest layer to replace. What still matters is the seam: the deal you create in the CRM has to end up paid in the ledger.

So it comes down to the thing that has to stay true forever: the ledger, the separation between businesses, who's allowed to do what, and the audit trail. That's the foundation — built once, carefully, then left alone.

But couldn't I just keep the accounting system and build the rest?

For a lot of businesses the honest answer is: yes, do that. Keep the ledger in something that files correctly. Keep a payroll tool that talks to the tax office. Vibe-code the CRM, the dashboards, the workflows. Best-of-breed plus a home-built surface is a perfectly good setup, and if it fits your business, this essay isn't trying to talk you out of it.

It stops being a good setup at the seams.

Every rule I've described is easy to keep inside one product. The dangerous failures live between products — and that's where nobody owns them. Consolidating several entities and cancelling out the transactions between them. A commission that has to trigger when an invoice is marked paid — in a different system. "This customer" meaning the same thing across your CRM, your finance tool, and your payroll tool. An audit trail that has to survive a process starting in one vendor's system and finishing in another's. The stuff holding it together — the fragile automation, the nightly export, the spreadsheet someone maintains by hand — quietly becomes the real system of record, and it keeps none of the rules, because no vendor's guarantees reach across into another vendor's product.

So the failure you were trying to escape just moves house. It leaves the CRM and reappears in the glue: plausible, quiet, compounding, and now genuinely nobody's job. Best-of-breed doesn't remove the hard part. It moves it to the place with the least ownership.

That's the real case for one system — not "one place" as a slogan, but one foundation where consolidation, commissions, "this customer," and the audit trail are single facts, not reconciliations between products. Below the line: the rules, enforced by the system, deliberately boring. Above it: workflows, views, automations, the tool your ops lead wants that no vendor will ever build — as easy to change as a spreadsheet, and safe to change badly. The question was never whether you're allowed to build. It's whether what you build can break the rules underneath it.

Where this leaves you

For a real slice of the stack, you should build. Start where being wrong is obvious and cheap — internal dashboards, that approval flow, the report nobody runs. It'll take less time than the procurement would have.

Then stop at the ledger. Stop at payroll. Stop at anything a regulator, a lender, or a future buyer will one day ask you to prove — not because you couldn't build it, but because the cost of it being subtly wrong is delayed, invisible, and paid by someone who isn't in the room yet.

So what are you paying for, in the part you don't build? Not the interface — you can generate that now. Not the workflows — those change every quarter. You're paying for the short list of things that have to stay true across every change anyone will ever make, including the one made in six weeks by an AI that never saw the original plan. That list is short. It's also the one part a weekend can't hand you, because it isn't a feature — it's a set of refusals built into the foundation.

A short test you can run this week. Take anything your team shipped last quarter and ask:

• Could two people create records with the same sequential number at the same moment?
• Could a small slip in a lookup return another company's data?
• Where does money get handled as an approximate number — and can you prove it doesn't?
• What happens if a payment notification arrives twice?
• Who changed that record, and when — and could you show it to someone with no reason to trust you?
• If a figure is wrong, how do you find out, and how long does it take?

If any answer is a shrug, that's not a bug to fix. It's a sign the thing was built on good intentions — and it belongs above the line, not underneath your money.

The choice was never buy-or-build. It's this: put a reliable foundation under the parts that must not silently fail, and build the flexible parts freely on top, where a mistake is cheap because the foundation won't let it reach the money. That's what we're building at Allwis — one system for the whole business, with the compliance and audit machinery underneath, and safe, open extensibility on top. Vibe-code away, on a foundation where the non-negotiables of running a business are already guaranteed.

Cultiver, our marketplace, hosts those extensions and helps builders sharpen them — checking quality, security, and commercial readiness. But the division of labour matters: that review tells you an extension is good. What makes a bad one harmless is the foundation it can't reach past. Review is for quality; the boundary is for safety.

I won't tell you it's finished. It isn't — we're building in the open with design partners, your data stays yours and portable, and I'd rather show you exactly where the line sits than sell you a platform that pretends the question isn't being asked.

The vibe coders have the right instinct. They've simply had nowhere safe to point it.

If you're running a services business in Australia or New Zealand and this is the line you've been trying to draw, we're taking on design partners.

Sources

• Business Insider, Curative CEO says company ditched a $600k-a-year Salesforce contract after vibecoding a CRM in 2 months — Turner's 20VC remarks: the cancelled contract, two-month build, 80% SaaS reduction target, and the provider-contract figure. Salesforce's response appears in the same piece.
• Salesforce Ben, Salesforce SMB Customers Switch to Vibe-Coded CRMs — reporting on The Information's original, which is paywalled; the figures here are as Salesforce Ben relayed them. Source of the 40–80% cost reduction, Greenleaf (David Codrea) and Oplign, and Mukherjee's comments.
• Salesforce Ben, Why Vibe Coding Isn't Ready for Most Salesforce Admins Yet — 2026 Admin Survey: 58.6% report rising complexity.
• Tim Combridge, Salesforce Ben, I Love Vibe Coding, But It's Dangerous and You Probably Shouldn't Do It — the builder-to-auditor argument.
• Cyber Unit, Vibe Coding and the SaaS Shakeup — Tenzai's December 2025 assessment: three identical briefs given to five tools (Claude Code, Codex, Cursor, Replit, Devin), 69 issues across the 15 resulting builds, business-logic flaws a recurring theme.
• SaaStr, 5 Simple Reasons We Won't All Vibe Code Our Own HubSpot or Salesforce — where self-built tools stop working.
• Forbes Technology Council (Alexey Spas), SaaSpocalypse: An Imminent Demise of SaaS or the New Moat-Building Era? — systems of record persist; the top layer moves out.

Martin Kratky is the founder of Allwis, an AI-native business suite for service businesses in Australia and New Zealand. He previously founded and sold Acterys, a business analytics and consolidation platform.