Asking a board to approve an own-your-AI build, a custom agent or internal platform instead of another subscription, is a different pitch to asking for ongoing AI reporting or a spending update. It is a capital allocation decision, and it needs a business case, not a status update. Most of the AI documents that reach a board are the wrong shape for this: too technical, too long, or built for reporting on something already running rather than approving something new.
Why this is a different document to a board update
A periodic board update on AI reports on governance, value delivered and management competence for a programme already in motion. A roadmap document gives a team a shared reference for what happens next. Neither is designed to get a first investment approved. A business case for an initial own-your-AI build needs to answer one question directly: why build this instead of continuing to rent it, and what does the board actually approve by saying yes.
The specific recurring cost the build replaces, stated as an annual figure, not a vague efficiency claim
The one-off build cost and the ongoing maintenance cost, kept clearly separate from each other
The payback period in months, calculated conservatively, not on a best-case adoption curve
The single biggest risk to the business case, and what happens if that risk materialises
Why one page, specifically
A board approving a first own-your-AI investment is usually doing so alongside twenty other agenda items in a meeting that runs to a schedule. A business case that needs pre-reading, or that buries the actual ask on page four of an appendix, does not get the same quality of attention as one that fits on a page and can be read in the room. The constraint of one page also forces the discipline of separating the actual decision, build versus keep renting, from the surrounding context a board does not need to approve anything.
This deliberately does not try to do what a full 90-day rollout plan or an ongoing board reporting structure does. It is a single-use document built for a single decision: approve the build, or do not, with the numbers laid out plainly enough that a director who has never used Claude can still follow the logic.
What tends to get cut, and what should not
The instinct when compressing to one page is to cut the risk section first, because it feels like the part most likely to talk a board out of approving. That instinct is backwards. A board is far more likely to approve a case that names its own weakest point honestly, an adoption risk, a dependency on one key staff member, a chance the recurring saving is smaller than modelled, than one that reads like it has no downside at all. Boards are trained to be sceptical of anything that sounds too clean.
What actually should get cut is the technical detail: which model, which framework, how the integration works. None of that belongs in a document a board is approving on cost and payback grounds. Save it for the implementation brief the team building it will use, not the document asking for the money.
A worked example
A 40-person professional services firm spending $54,000 a year across four separate AI subscriptions built a one-page case for consolidating onto a single internal Claude-based platform, build cost $28,000, projected first-year saving $31,000 after maintenance, payback inside eleven months. The board approved it in the same meeting it was presented, specifically because the entire case, including the risk section, fit on one page and left no follow-up questions unanswered.
What goes wrong without this discipline
The most common failure mode is not a board saying no, it is a board deferring a decision because the case was not concrete enough to approve on the spot, and a deferred AI investment decision often quietly dies on a future agenda that never gets reached. A tight, one-page, numbers-first case is what gets a yes or a no in the room, rather than a maybe that becomes a no by attrition.
Where Automata fits
Automata builds this business case as part of scoping an own-your-AI engagement, using the business's actual subscription spend and a conservative build estimate, not an industry-average guess, and the risk section reflects what could genuinely go wrong with that specific business, not a generic disclaimer.
If your business is weighing a build-versus-rent decision and needs a board-ready case, book a session at /contact and bring your current AI subscription spend so the numbers in the case are real ones.
