You have one process everyone agrees is broken, a quote you cannot defend to whoever approves it, and someone upstairs asking for a number. The pressure is to authorize something, the one move nobody is blamed for. That is where the money goes wrong.
The step that protects you is the one whose best possible result is that you spend nothing else. It has to be allowed to end in do not build this, without leaving you committed to anything. For you that step is a fifteen-minute call with a clear answer at the end of it.
A major US TV network came to the call holding a quote to build a full software system for a workflow that did not require one. The conversation stopped that build before it started — the workflow needed a fraction of the machinery it had been priced for — and the network kept the rest of its budget. Their AI Program Manager put the outcome on the record:
Omar delivered in two weeks what our team estimated would take six months. The scoping session alone saved us from a $200K mistake. He operates at a level you rarely see in this industry.
— AI Program Manager, a major US TV network
Sometimes the useful outcome is do not build this, the highest return at that price.

Why The Decision Costs More Than The Build
The share of generative-AI projects abandoned after proof of concept (Gartner, 2024) is projected at 30% by the end of 2025. Research on AI project failure patterns (RAND, 2024) locates the damage upstream of the engineering, in the gap between the outcome intended and the system being built. The failure is authorized long before it is engineered.
The cost gradient is why this earns its own step. The classic finding on software defect reduction (IEEE, 2001) is that fixing a problem after delivery costs roughly a hundred times more than fixing it while requirements and architecture are still on paper. Not building is the lowest-cost fix on that curve, and it is only available before the money moves.
What A First Call Owes You
You should end that call holding four things; ask for them directly if they are not offered.
- A plain yes or no on whether your workflow is worth building. Not "interesting", not "let us put something together". A position that is stated on the call.
- The size and the shape. One workflow, with its scope fixed before any work starts, and also which parts of your own process fall outside of that boundary.
- The two or three facts that would change the answer. In almost every case these are where the data actually lives, and who inside your organization can grant access to it.
- If no, a one-sentence reason you can repeat. One you cannot repeat is one you lack.
Fifteen minutes cannot tell you that your data will behave once code runs against it, and it cannot produce a document that a committee or a board can fund against.
When A Written Plan Is Worth Paying For
There are two situations where paying for a written artifact before the build is the right move. The first is when the approval runs through people who were not on the call: a finance committee or a board that funds against documents. The second is when the decision is contested inside your organization and the argument has stalled. A written recommendation with a side, produced by someone with no stake in which department wins, ends that where another meeting will not. Raise it on the call and you get it in writing; it is optional, not a gate before the build. If you already want the work done, say so and the build starts.
What The Written Plan Has To Contain
A written artifact earns its price by ending in things a person who was not in the room can act on. The one you receive contains five, and the shape matters more than the price:
- The plan itself. Detailed enough that another engineer could dispute specific points.
- A budget number with its assumptions stated. A number with no assumptions cannot be checked by anyone, and therefore cannot be defended to an approver.
- A go or no-go, in writing. Not "promising". A recommendation which takes a side, including the answer do not build this when that is the honest answer to give.
- The risks that would sink it, ordered. Sorted by which one would end the project first.
- The next step and what it costs. So the next decision is priced before you reach it.
Notice what is not on that list: a maturity review, a market landscape, a roadmap with quarters on it. Once the answer is build, your question becomes whether the vendor is safe to sign, and you can settle that question with how to judge what a vendor hands you.
What Has To Be True Before Any Of It
There is one hard prerequisite, and it is not technical. Someone on your side names the process, names the data, and can grant access to it. One owner, empowered to make those calls. If nobody can produce a named process, named data, and an owner who can grant access, no larger engagement has a target to hit. That absence is in itself the finding, and the first call is where you should discover it rather than after the build is paid for.
The Numbers You Are Comparing It Against
The build is one workflow becoming software that runs every day, scoped in writing before work starts, with targets agreed before the first line is written. It runs in an ML LABS repository and transfers to you as it is paid for — code, intellectual property and full history.
Running it afterwards is its own decision: $10,000 a month, and deliberately hands-off. It covers monitoring, incident triage, a standing review of cost and drift, and the audit trail kept intact. It writes no code; there is no change allowance, and new work is quoted as a new engagement. It runs month to month, ending on 30 days' notice from either side.
That is the number the first call is measured against, and the comparison is rarely close.
Take The Short Step Before The Long One
Bring the one process you cannot stop arguing about to a fifteen-minute call. Nothing is paid, nothing is signed, and the outcome may well be that this should not be built.
If what comes back is do not build this, that is the result you paid almost nothing to get.
References
- Gartner. Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept by End of 2025. Gartner, 2024.
- RAND Corporation. Analysis of AI Project Failures. RAND Corporation, 2024.
- Boehm, B., & Basili, V. Software Defect Reduction Top 10 List. IEEE Computer, 2001.


