For years, the build-or-buy decision was made vertically. Buy the whole application from a specialist vendor, or, with the rise of AI-powered ‘vibe coding’, build the tool yourself fast and cheap. But the underlying information layer is as hard to get right as ever. Generating documents, handling multiple file formats, making everything searchable (including scans and drawings), or tying chatbot answers to a traceable source: these are the tricky and critical elements you cannot trust AI to improvise. What’s worse, every app that reinvents them creates more fragmentation and risk than efficiency and speed. So the line now runs horizontally: for vibe coding to pay off, apps must sit on a foundation that already gets the hard parts right, explains AODocs CEO Stephan Donzé.
Until recently the choice for companies was simple and unpleasant.
Either buy a specialized tool for each team – legal, HR, procurement and so on – and live with its interface, data model and renewal terms; or you can build your own app, wait a year or two for it to be delivered and then deal with whatever shortcomings pop up.
The easy part: The rise of vibe coding and build-your-own
With the rise of AI-powered, low-code ‘vibe coding ’, the second option, namely ‘build your own app’, now costs a fraction of what it did even a year ago. Someone who knows the process can describe the screens, flows and rules they want and have a working app running by the end of the week. Teams that would never have tried their hands at development are shipping tools that fit how the work is actually done.
The tricky part: Critical pieces, hard-to-build blocks
So the DIY screens and interfaces got cheaper, easier and faster to deliver. But the key consideration in the new equation is this: you cannot let AI improvise the infrastructure that ensures apps’ proper function.
Ask an AI agent to build a contract app and you will get one. Along with the flashy interface, you will also inherit a set of architectural decisions nobody monitored or governed: where the files are stored, who can see business-critical documents, what happens to the old version when someone uploads a new one, whether anything is logged and traceable, what “approved” means and who gets to say so.
The AI will not raise these with a human manager but rather pick something that looks sensible and carry on. You asked for a working app and that is what the agent is delivering.
Those are the decisions that can cost in safety hazards, regulatory violations and money later, usually at the worst possible moment: an audit, a dispute, a version that cannot be produced when somebody asks for it.
On top of this, come the more complicated components the AI agent will attempt building. Document generation that works in the demo might break when deployed on a real-world contract with annexes. Format handling that covers PDF and Word can quietly ignore drawings and search might overlook essential data that scans contain.
Finally there’s grounding chatbot responses in validated and up-to-date content. An app that cannot tell which document an answer came from is an app you cannot use for anything that carries consequence.
Fragmentation and unsupervised siloeing: When each team gets its own disparate infrastructure
Every team that builds its own tools “easily with AI” makes calls separately. Legal and procurement can each design their own permission model, while HR keeps its files somewhere else entirely and holds its own view of what “current” means.
Three teams in, a company is running three document stores, sets of retention rules and AI agent layers, each able to answer half of any question that crosses a boundary.
Your exposure is nowhere and everywhere if a supplier goes into administration, with the contract in one system, the purchase orders in another and the invoices in a third. Ask the AI, and you will get three partial answers, each correct within its own perimeter and useless together.
Then there’s a second risk which surfaces. The specification the engineer emailed, the amendment someone scanned onto a shared drive, that deck holding the only written record of what was agreed in the room: none of it was ever in scope for any of these apps. Some documents might even be in two different systems, as two separate and slightly different copies
The file sits where it always sat, in the condition it was always in.
Point an agent at it and the AI will believe the file and retrieve an answer from it, because nothing inside the file says “this one is void” or “this is the validated version.” A person who knows the history can usually work it out. An agent will quote the expired policy back to you with complete confidence.
You have built three islands of seeming order, with the water between them murkier than ever.
The question: What horizontal layer do you build your apps on?
None of this means you should ban teams from building their own applications. Telling procurement to go back to an off-the-shelf specialized suite because the in-house AI-powered version has a permissions problem is not much of a solution.
The answer is to stop building the same foundation multiple times.
For years the build/buy decision ran vertically. Buy the whole application from a specialist vendor, or build the whole thing yourself. Either way the interface and the foundation came bundled, which is what made the choice painful.
Cut it the other way instead. Buy the foundation once, as shared infrastructure and system of record for every application built on it. Build the interfaces and the business rules on top, per team, per process, with AI doing most of that work.
The interface is now the cheap part, so it should keep changing as the process evolves, which is what a specialized tool never allows.
The foundation stays put as one governed space for the documents, and as many interfaces above it as you have teams.
What has to be in the cross-cutting foundation
Not every part of that foundational layer carries the same risk, and it helps to separate them.
The parts that must be robust. Storage, metadata, permissions, versioning, workflow, traceability. An AI assistant will improvise it without pausing with costly and mostly irreversible mistakes as a consequence: incomplete permission model, version history or audit trail. This work has to be done properly once instead of poorly many times.
The parts that are hard to get right. Generating documents from structured data. Handling the many formats your business runs on. Making the entire body of content searchable, including scans and engineering drawings. Keeping AI answers tied to the source they claim to come from. Building these takes years, and they get restructured badly every time somebody starts over.
Lifecycle state. The foundation has to hold a machine-readable answer to one question about every document it governs: is this valid, current, approved, or superseded? Many “AI-ready content” solutions on the market optimize for access and enrichment, helping an agent find and understand things but not which of the three contracts it retrieved is the one in force.
For best results, enterprises can pick and arrange the components per process needs and call them from their own code or agents.
How this works in practice: Two real-world examples
A procurement team came to us expecting to buy a software suite. Instead, we delivered an interface sitting on a configured foundation: their screens, their approval rules, their supplier data, all on top of governed documents. The experience stands comparison with the packaged product, they can change it when the process changes, and they own the information rather than renting access to it.
A retail distributor was running sales orders on paper and email, with the error rate you would expect. We replaced it with a mobile app for the sales team, with AI reading the incoming documents, pulling out what matters and generating the order paperwork on the way back out. The app is theirs and specific to how they sell. The document handling underneath is not something they had to build, or maintain, or explain to an auditor.
Same split for both clients: the foundation handles the building blocks you must get right, the app handles what makes the tool theirs.
Run the numbers on the third use case, not the first
Compare the two models where it counts: risk, time and, let’s face it, money.
With a specialized tool per department, the second and third application cost roughly what the first one did. New licence, new integration, new store, new project, new migration, another perimeter your AI cannot see past. Nothing you paid for the first time reduces the price of the next tool. Build each one from scratch and the arithmetic is no better, with the architectural gamble taken fresh every time.
On a shared foundation the second and third applications are mostly about interface. Storage, permissions and workflow are already there, and the documents are already governed. The marginal cost falls with each use case rather than holding flat.
One deployment is already competitive on price; by the third, the comparison stops being close.
That is the calculation worth running, unlike the one for a licence-fee comparison.
Your next move: Go horizontal or vertical?
Whether you are about to buy or build, ask which part you are actually paying for.
If it is the domain expertise, it may be worth buying it. But if it is the governed layer underneath, you are about to acquire it for the umpteenth time, in a form that will not speak to the other apps or tools you use.
Your teams deserve to use applications that match how they work. But they should not each get a disparate answer to where the documents live, who can open them, and which version counts.
That is what we built AODocs to be: the cross-cutting foundation your applications and AI agents can rely on, so the difficult parts that have to be right are handled, and the parts that make each application worth having are yours to handle and evolve per your needs.
To see AODocs document foundation in action, get your demo now
