Key takeaways
- The hard parts of a management system are invisible in a demo — tenancy, permissions, concurrency, audit, migrations.
- Business software fails silently. Wrong numbers look exactly like right numbers.
- Use one test: if this is wrong, how will I find out? Immediately and obviously — vibe-code it. At an audit — don’t.
- Vibe-code the edges: throwaway analysis, prototypes, data shaping, internal dashboards, test data.
- The third option is a platform where the risky parts are already right and the rest is configuration your AI can safely change.
Give a capable model an afternoon and it will produce a working inventory app. Real login, real tables, a dashboard that looks like the ones in the pitch decks. The demo will be genuinely impressive, and the temptation that follows is completely understandable: if it can do that in an afternoon, why are we paying for a system?
It is a fair question, and the answer is not “AI can’t code”. It obviously can. The answer is that a management system is one of the worst possible places to find out where the limits are.
What vibe-coding is genuinely good at
Worth being clear, because the point here is not caution for its own sake. AI-assisted coding is exceptional at getting from an idea to something you can look at. It is fast, it is cheap, and it removes the activation energy that kills small useful projects — the ones nobody would ever fund a developer week for.
It is at its best where being wrong is cheap and obvious. If the script produces a chart that looks insane, you notice within seconds and try again. Nothing is at stake but your afternoon.
Why your management system is the wrong target
The screens are the easy part. What makes business software hard is almost entirely invisible in a demo.
Scoping and permissions. Every query needs to be limited to the right company, the right site, the right user. Get it wrong and nothing crashes — you simply return someone else’s data, and you find out when a customer tells you.
Concurrency. Two people receive the same delivery at the same moment. Two invoices claim the same number. These bugs do not appear in testing, because testing is one person clicking slowly.
The unglamorous 90%. Migrations that preserve live data. Backups you have restored at least once. An audit trail. Soft deletes. None of it is in the prompt, and none of it shows up in the demo.
Business software fails silently. A wrong number looks exactly like a right number, and the invoice goes out either way.
Statutory correctness is not something you can eyeball
This is where the gap becomes uncomfortable. A tax document has to be valued at the VAT rate that applied on its own date, not today’s. Statutory numbering has to be gapless and assigned when a document is issued, not when someone opens a draft. Reporting files have fixed field widths, and a value one character too long is silently truncated into something that matches nothing.
Every one of those rules produces output that looks completely fine. You do not discover the mistake when you make it. You discover it in an audit, a year of documents later.
Watch out for
Fields that look like they do something. The most dangerous bug in this class of software is a setting that saves successfully and is then ignored by the engine. Somebody ticks “pensionable” on a salary component, the form confirms it, and the calculation never reads it. Nothing errors. It is simply someone’s pension, quietly wrong, until the year it is noticed.
And then it has to survive
Software you generated in an afternoon still has to be alive in three years. The framework will age. The person who prompted it will move on, leaving code nobody else has read. There will be no tests, so nobody will dare change it, so it will calcify exactly as the spreadsheet it replaced did.
Meanwhile the rules keep moving. Tax brackets change in January. National insurance rates change. A reporting format gets a new revision. Whoever owns that maintenance is a real, recurring cost that never appeared in the afternoon’s estimate.
The test that actually decides it
Forget categories of software. Ask one question about whatever you are about to build:
If this is wrong, how will I find out?
If the answer is “immediately, and obviously” — vibe-code it, and enjoy it. If the answer is “at month end”, “from a customer”, “from the bank” or “at an audit”, then you are not choosing a build method, you are choosing how much risk to carry silently. That is a different decision, and it deserves a different answer.
So what should you vibe-code?
Plenty. This is not an argument for doing less of it — it is an argument for pointing it somewhere useful.
One-off analysis. Reconciling two exports, finding duplicates before a data migration, checking whether a supplier’s prices moved. Code you throw away the same day is the perfect target.
Prototypes to decide what you want. Building a fake version of a screen is the cheapest way to discover that the process you described is not the process you run. Learn from it, then configure the real thing properly.
Shaping data at the edges. A supplier who sends a peculiar CSV. A machine that exports something nearly usable. Small, testable, and wrong in ways you notice at once.
Internal read-only dashboards. Reading is far safer than writing. If it only queries, the worst case is a confusing chart.
Test data, documentation and runbooks. Unglamorous, universally skipped, and genuinely improved by having a model write the first draft.
In practice
A useful rule of thumb: let AI write anything that touches a copy of your data, and be deliberate about anything that writes to the original. Most of the value is on the read side anyway.
The option most people miss
The choice is usually framed as build-it-with-AI or buy-something-rigid. There is a third position, and it is the one worth arguing for: a platform where the parts that must be right are already right — tenancy, permissions, audit, statutory reporting, payroll tables — and the parts that are specific to your business are configuration rather than code.
That matters for AI specifically, because configuration is exactly what a model is good at proposing and exactly where a mistake is cheap to reverse. You are not asking it to invent VAT handling. You are asking it to define a record type, wire a rule, or draft a report — inside a system that will reject anything invalid.
Where Capitán fits
Capitán is built as that third option. New kinds of record are defined, not developed — and they get real database tables, real constraints and real company scoping, not a bag of custom fields bolted onto something else. Rules and approvals are configured. The accounting and statutory reporting are already built and already maintained, which is precisely the part you should never generate from a prompt.
And Capitán ships a Model Context Protocol server, so your AI assistant can work inside it directly — querying data, running reports, creating records. It connects as a named user and goes through the same validations, triggers and company scoping your staff do. The assistant works through the rules rather than around them, which is the difference between a useful colleague and an unaudited script with database access.
If you are weighing building something in-house against configuring it, talk to our team — we will tell you honestly which parts are worth building yourself.
The short version
Vibe-code the things that fail loudly. Buy the things that fail quietly. Then point your AI at the system you bought, where a mistake is a configuration change rather than a compliance problem.