Vibe ERP explained — describing what you need instead of configuring modules

Vibe ERP is a way of building business software in which you describe the outcome you want in plain language — "I need to track service jobs from enquiry to invoice, with a supervisor sign-off before we bill" — and the system generates the module, the forms, the approval flow and the dashboard to match. You do not configure modules. You do not map fields. You describe, review, and adjust.

The name borrows from vibe coding, the term Andrej Karpathy coined in early 2025 for a way of programming where you describe intent to an AI and steer the result rather than writing each line yourself. Vibe ERP is that idea pointed at business systems instead of code — with one important difference we will get to.

Where the term comes from, and why it matters

Vibe coding worked because a threshold was crossed: models got good enough that describing intent produced working software more often than not. Developers stopped typing syntax and started reviewing output.

Business systems are, structurally, the same problem. An ERP module is a data model, some forms, a state machine and a few reports. Historically that took a consultant to translate from "how we work" into "how the software must be configured". That translation layer — the requirements doc, the blueprint phase, the change request — is the expensive part. It has always been the expensive part.

Vibe ERP removes the translation layer. You describe the process; the system produces the software.

The difference from vibe coding is who is doing it. Vibe coding is for developers who could have written the code themselves and chose to go faster. Vibe ERP is for the operations manager, the finance lead, the founder — people who could never have built the module at all, and for whom the alternative was not slower code but a spreadsheet, a WhatsApp group and hope.

What it looks like in practice

The loop is short:

1. Describe it. "Purchase requests. Anyone can raise one. Anything over RM5,000 needs the finance manager to approve. Attach a quote. Show me what is pending, by department."
2. The system builds it. The data model, the request form, the conditional approval rule, the attachment handling, the dashboard.
3. You look at it and react. This is the part people underestimate. Reacting to something real is dramatically easier than specifying something imaginary. You will immediately notice that you also need a rejected-with-reason state — something no requirements workshop would have surfaced in three hours.
4. You say the next thing. "Add a reason field when it's rejected, and notify the requester."

That is the whole method. Describe, look, react, refine.

Why this beats low-code (which promised the same thing)

Low-code and no-code platforms made a similar pitch for a decade: business users build their own apps, no developers needed. Some of it landed. Most of it did not.

The reason is that low-code did not remove the translation layer — it moved it onto you. You still had to decide the data model. You still had to know that this is a one-to-many relationship, that this field needs to be a lookup and not a text box, that this automation must fire on update and not on create. The drag-and-drop canvas replaced typing with clicking; it did not replace thinking like a software designer.

So the tools got adopted by exactly the people who could already build software, and everyone else quietly went back to Excel.

Vibe ERP's claim is narrower and, we would argue, more honest: you should have to understand your business, not the software. You must be able to say "anything over RM5,000 needs finance to approve". You should not have to know what a foreign key is.

What you still have to bring

This is where we part company with the more enthusiastic end of the market.

You have to know your own process. This is the real constraint, and it catches people out. "Build me an inventory system" produces something generic and disappointing. "We hold stock in two outlets and a warehouse, transfers need a receiving confirmation at the other end, and we count monthly" produces something useful. The system will faithfully build whatever fog you describe.

You have to review the output. Generated is not the same as correct. Someone who understands the process has to look at what came back and say yes. Most of the failures we have seen are not the AI building the wrong thing — they are nobody checking.

You have to think about governance early. When any manager can spin up a module in an afternoon, you get the same sprawl that spreadsheets created, just faster. Who can create things? Who approves? What is logged? These questions are not bureaucracy; they are the difference between a system you can audit and a mess you cannot.

Some things still need a specialist. A gnarly integration with a legacy accounting system, a migration of fifteen years of records, a genuinely unusual costing method. Describing it does not make it simple. It makes the building faster; it does not make the problem easier.

The honest boundary

Vibe ERP is very good at the long tail — the hundred small, specific processes that make your business yours, that no vendor ever built a module for, and that were never worth a change request. Job sheets. Site visits. Sample requests. Warranty claims. Approval chains that exist because of one incident in 2019.

It is less differentiated on the deeply standardised core. Double-entry bookkeeping is double-entry bookkeeping. If all you need is a general ledger, plenty of mature software does that well and cheaply, and you should probably use it. We say as much on our comparison pages.

The interesting position — and the one most businesses in this region actually occupy — is having a perfectly good accounting package and no way to handle the twenty processes that surround it. That is the gap. Vibe ERP fills the gap without asking you to rip out the thing that works.

Common questions

What is Vibe ERP?

Vibe ERP is a way of building business software where you describe the outcome you want in plain language — "I need to track service jobs from enquiry to invoice, with a supervisor sign-off before we bill" — and the system generates the module, the forms, the approval flow and the dashboard to match. You do not configure modules or map fields. The loop is short: describe it, look at what came back, react, then say the next thing.

How is this different from the low-code tools that promised the same thing?

Low-code did not remove the translation layer between how you work and how the software must be configured. It moved that layer onto you: you still had to decide the data model, know that this is a one-to-many relationship, that this field needs to be a lookup rather than a text box, that this automation fires on update and not on create. So the tools were adopted by people who could already build software. The claim here is narrower — you should have to understand your business, not the software.

Will it work if we are not sure how our own process runs?

Not well. The system will faithfully build whatever fog you describe: "build me an inventory system" produces something generic and disappointing, while "we hold stock in two outlets and a warehouse, transfers need a receiving confirmation at the other end, and we count monthly" produces something useful. Knowing your process is the real constraint. Someone who understands it also has to review the output, because generated is not the same as correct.

What still needs a specialist?

A gnarly integration with a legacy accounting system, a migration of many years of records, or a genuinely unusual costing method. Describing those does not make them simple — it makes the building faster without making the problem easier. Governance is the other thing to settle early: when any manager can create a module in an afternoon, deciding who can create things, who approves and what is logged is the difference between a system you can audit and a mess you cannot.

Is this just a rebrand?

Fair question. Our answer: the name is new, the shift is not.

Every era of business software has been defined by who is allowed to change it. Mainframes: programmers. Client-server ERP: consultants. Cloud ERP: administrators. Each step widened the group slightly and cost slightly less.

Vibe ERP widens it to anyone who understands the process. That is either the last step in a long sequence or a genuine break, depending on how much of a purist you are. Either way, the practical consequence is the same: the person who knows how the work actually happens is now the person who can change the software. For most businesses, that person has never been in the room before.

Whether the label sticks is not really the point. The capability is here regardless.

More on the architecture behind this in what is an AI-native ERP, and on timelines in the death of the 18-month ERP implementation.

The next step is usually smaller than people expect. Talk to us about one process worth starting with.

Also worth reading: introducing SmartB Studio.