Three proposals arrive for the same business outcome, each argued on its technical merits. The decision does not turn on the technology. It turns on how the work is organized and on who is out of pocket if it is late.
The Decision
What Is On The Table
Your technology team wants to build it. AI tools have made development far faster, the cost is one-time, and they price it at roughly two years of licensing.
Your consulting partner proposes their own orchestration platform, or a formal process to survey the market first.
Your architecture team recommends an accelerator, which is the option most likely to be unfamiliar.
An accelerator is a partly finished solution to a specific business problem in your industry. The common work is already built — the process itself, the rules everyone in your sector shares, the connections into the systems everyone in your sector runs. What remains is fitting it to how you work, and the vendor’s own engineers do that inside your business rather than shipping software over the wall.
It is not a platform that replaces your systems, and it is not a blank page. You license it a piece at a time, pay for what you use, and it runs on your own systems with your data staying where it is.
One option can go immediately. An orchestration platform carries no knowledge of your business, so everything that makes your outcome yours still has to be built on top of it — you pay for the foundation and still owe the building. Ask them to show it solving your problem, in your industry, for a customer in production. If that does not exist, you are buying plumbing.
The key point:
A platform with no domain knowledge in it leaves the real work undone.
What AI Changed, and What It Did Not
The build case is stronger than it was two years ago, and your team is not exaggerating that part.
What moved is the time to write software.
What did not move is the time it takes your organization to agree, decide, and hand off. On most builds, that is the larger number — and it is the number nobody puts in the estimate.
The key point:
AI writes software faster. It does not make ten leaders agree faster.
Count the Reporting Lines
Ask who owns the build and you will hear a name, usually the CIO. That settles nothing. Eventually everyone reports to the CIO.
The question is how many separate lines the work crosses before it reaches that person.
Infrastructure, networks and data sitting apart is normal, and projects survive it. The narrower test is the five functions closest to the work: the person defining what to build, the people building it, the people testing it, the people connecting it to your other systems, and the person coordinating all of them, who usually sits in a group of their own.
Five functions in one line is a team. Their estimate probably holds.
Five functions in five lines has no single place where a decision gets made. Your sponsor can convene, escalate and ask. They cannot direct. The project turns red gradually and nobody can tell you which week it happened.
The key point:
Everyone reports to the CIO eventually. Ask how many lines the work crosses before it gets there.
Who Writes the Definition
You know what happens when requirements are weak. The part worth noticing is what AI did to that problem.
Nothing.
AI turns a definition into software very quickly. It does not produce the definition. So the constraint that was always there is now the whole constraint, and it decides most builds.
Which makes the question concrete rather than philosophical: name the person who will write it, and confirm they are available for the duration.
If you cannot, a product is somebody else’s definition, argued out across many customers before you arrived. Reacting to that is a far easier thing to ask of a busy organization than starting from a blank page.
It also arrives with an edge. A product does what it does, and crossing that line has a price attached to it. A build has no edge, so every request is possible and every request gets discussed. That is not indiscipline. There is nothing to refuse against.
The key point:
AI turns a definition into software. It does not write the definition.
Who Is Late At Their Own Expense
This is the part that rarely gets said out loud.
An accelerator vendor does not get paid until it is running. Their revenue depends on your deployment date, which puts their money at risk on your timeline.
On an internal build, nobody’s money is at risk. The team is paid the same whether it ships in March or September.
Two more things come with the vendor. They start closer to the finish line, so the work is configuration rather than development, done by people who have done it before. And their team reports to them — the coordination problem you were just counting lines for is theirs, already solved.
None of which makes the accelerator automatically right. It still has to meet real criteria on pricing, deployment and engineering model, which I have covered in what the model is and how to select a vendor for it.
The key point:
A vendor who gets paid on delivery has something at stake that your own team does not.
Final Thoughts
The discussion in the room will be about technology. Almost none of it decides the outcome.
Three things do. How many organizations have to cooperate. Whether anyone can say precisely what the system should do. And whose money is at risk if the date slips.
All three can be answered without knowing anything about the technology, which is the point. You are not being asked to evaluate an architecture. You are being asked whether this organization, as it is currently arranged, can deliver what is being promised.
A build under one leader with a real definition behind it is often the right answer, and more often than it was two years ago. A build spread across five organizations with nobody to define it is a red project that has not started yet, and no amount of AI changes that.
And if only one option reaches you, that is its own answer. Send them to survey the market. Surveying it is a delay when you already know the alternatives, and the only sensible step when you do not.
Ask how many lines the work crosses.
Then decide.
Tech Canvas 