Vibe Coding and Composable ERP: When Custom Apps Actually Make Sense (and When They Don’t)

Every executive planning session is probably chasing the same dream: an ERP that behaves like Lego bricks. Today, the hype around vibe coding promises to let anyone snap these bricks together with zero engineering experience.

But there is a vast gap between generating a personal app on your laptop and running an enterprise workflow. And crossing that gap without a clear strategy can end up very badly.

Take a look around: read social media, watch youtube videos, and check almost any industry meetup today: you will hear people pitching custom tools built in a couple of afternoons using a popular LLM. Everyone focuses on the shiny frontend functionality. But ask about where that database is backed up, or how they plan to manage disaster recovery, and you will get nothing but blank stares.

I see this pattern growing also across the ERP industry. People are proposing a standalone app for every minor operational request, immediately spinning up a prototype, generated by an LLM, before they have even gathered the initial requirements.

The frenzy of creating software without having the actual competence to build it has gone through the roof. Today, everyone thinks they are a developer.

Let me be clear: I am not a developer, and I have absolutely no intention of becoming one. This does not mean I will avoid vibe coding to support my ideas, but I am under no illusion that we can solve complex business problems with half-baked applications built without strategic thinking.

The biggest issue right now is the cultural climate. If you raise any technical objection or ask about data integrity, you are immediately labeled as the “anti-vaxxer” of generative AI, a skeptic who refuses to embrace innovation.

But asking hard technical questions before deploying half-baked tools is not skepticism. It is the baseline of critical thinking. Expecting a flawless, enterprise-grade tool created in 72 hours by prompting with zero technical expertise is pure delusion.

The steps in consulting and system design remain exactly the same. You gather requirements, ask questions, and guess what? Ask more questions. If you don’t understand the exact operational flow you are trying to replace or optimize, how on earth do you expect to build something useful?

Vibe coding doesn’t replace the design process; it merely accelerates a small part of it. The rest of the workflow remains unchanged.

This trend is colliding with the evolution of enterprise software. For years, companies have struggled to balance standardization with customization. The dream of a modular, flexible system is as old as the ERP industry itself, but the tools to build it have changed.

The Single Database Dogma

To understand why we are here, we have to look back. Before today, the golden rule of IT architecture was centralization. If a business process didn’t fit the standard ERP template, the default response was to build a custom modification directly inside the core system.

This approach was driven by a specific belief: keeping all transactional data in a single database was the only way to ensure reliable business intelligence. If every department, from sales to warehousing, queried the same tables, reporting was simple and clean.

In theory, it was a logical strategy. In practice, it turned the core ERP into a monster.

Over decades, these custom modifications accumulated, resulting in a heavy layer of unstructured data, orphaned tables, and undocumented business logic. Today, in the era of generative AI, this legacy is causing a lot of headaches. Companies trying to implement advanced search or automated agents find that their data is too dirty and fragmented to be usable.

From Monolith to Modules

As monolithic systems became too rigid to upgrade, the market shifted toward the composable ERP architecture. Instead of force-fitting every process into a single software suite, organizations began selecting best-of-breed SaaS products for specific departments.

The philosophy is simple: if there is a highly optimized, standard tool for CRM or field service, why would you build a custom one from scratch? You subscribe to the specialist vendor and connect it to your core ERP via standard APIs.

This architecture keeps the core system clean and reduces upgrade risks. It allows the IT department to act as an orchestrator, focusing on integration rather than custom code.

However, even the most comprehensive composable ERP setup leaves a gap. Every business has highly specialized micro-processes that reflect their unique operational habits or physical layout.

The Micro-Requests Gap

These micro-requests are the bane of IT departments. They are too small to justify licensing an external SaaS product, but too specific to ignore. Customizing a third-party tool to support them often costs more than the process is worth.

Historically, these gaps were filled by shadow IT, usually in the form of complex Excel spreadsheets maintained by a single operator. Now, the emergence of vibe coding suggests a new alternative.

Within the next year, the ability to generate a functional web application will become a commodity. Anyone with a basic understanding of their workflow will be able to prompt a coding agent to build a custom tool. And this prediction is not mine alone. Companies like Replit are building entire platforms around the idea that anyone can bring a product to life.

For companies, this looks like the best solution to the micro-requests gap. Operators can build their own micro-apps to track specific tasks without touching the core ERP database. But before we declare traditional software engineering obsolete, we need to examine where this approach works and where it fails.

Where Custom Code Actually Belongs

Generating custom applications using AI makes sense under very specific conditions.

First, the application must take care of a completely isolated, standalone flow. It should wrap around the core ERP rather than attempt to extend or modify it. If the app only reads data from the ERP and doesn’t attempt to write complex transactions back, the risk is minimal.

Second, it makes sense when the process is so unique that no commercial software could support it without heavy modification. Designing a tool specifically for your unique operational steps is far better than forcing a standardized tool to behave in ways it was not designed for.

A good example is a simple utility for a logistics clerk to track the physical location of temporary racks in a specific loading bay. It solves a local problem, runs on a separate database, and does not interfere with the company’s financial records.

Where the Budget Bleeds

The trouble begins when organizations try to use vibe coding to replace broad, complex enterprise modules.

If a company lacks the internal software engineering expertise to read and debug the generated code, they are walking into a trap. The initial creation of the app is fast and cheap, but maintenance is a long-term burden.

I’ll be transparent on this: vibe coding is an excellent tool for an individual who wants to build a personal investment dashboard. It’s also a dangerous liability when it runs a business-critical flow and the operations team cannot read 10% of the code produced.

And we are not talking about 500 or 1000 lines, but a lot more, all of which need to be revised when something breaks. The moment a bug disrupts the production line, the cost of downtime will outweigh any initial savings.

We must remember that generative AI is an accelerator, not a replacement. All those managers who thought they could lay off human labor are currently realizing that humans actually cost less.

Less than those systems that politely say “you are right, I will fix it immediately” at every mistake, only to fail again in the next execution.

Furthermore, using vibe coding makes no sense when a standard, license-free open-source product already exists. One of the most interesting global side-effects of the vibe coding boom is the enormous surge in open-source contributions. Developers and hobbyists who used to guard their custom scripts like private treasures are now publishing them, creating a shared library of tools.

If a free, community-vetted template can be adapted to your process, starting a custom build from scratch is just burning through your budget.

Beyond the Vibecoder Cap

Before you call in the classic genius wearing a “vibecoder” cap, who would gladly build a custom app just to count how many times he goes to the bathroom, take a step back.

Reinventing the wheel is a fun exercise when you have no budget constraints and no actual operations to protect. But in the real world, building a custom tool instead of evaluating what is already available is a reliable way to stall your workflows.

Run the numbers and research what the market already offers. Building your own ERP using a puzzle of AI-generated apps is not innovation; it is simply a more modern way to accumulate technical debt.

The priority for leadership is not to generate more software, but to ensure that existing systems are clean, standardized, and properly integrated.

Written by Andrea Guaccio 

June 30, 2026