Build vs Buy: What Should Your Business Own in AI? | Rudi Khoury, Fisher & Paykel

Buying software rarely solves an operational problem on day one. It usually shifts who does the work. Vendor proposals leave your team's share of that labor off the invoice, creating an illusion of speed while moving the mess into your operations.

---

Operational evidence

Rudi Khoury, Chief Digital Officer at Fisher & Paykel, tried building an AI service agent across 35,000 product documents before buying a commercial solution.

His team managed user manuals, care guides, and installation instructions for products that remain in homes for over 20 years. A wrong installation step meant immediate brand and safety liability.

Their first build combined a language model with custom software, but controlling which information it used proved difficult. Even after buying a vendor solution, the agent required repeated data reorganisations, prompt adjustments, and continuous internal checking.

Buying supplier expertise did not eliminate the operational workload.

McKinsey's survey found that 32% of organisations have already rejected a software purchase because they could prototype it internally using coding tools.

The assumption that buying software is the default path to capability is broken.

Consider a simple operational requirement like a weekly service report. Every Monday, an operations manager needs overdue cases, reopened cases, and a named owner for each record. The CRM already holds the data, but a supplier quotes for an add-on module to produce the layout.

Evaluating the vendor interface doesn't consider the operational risk. Which appears when a case status changes mid-export or a delivery fails.

If an operations manager spends two hours every Monday re-keying case ownership and reconciling broken exports, that is 100 hours of senior capacity lost annually.

Multiply that across three business units at a fully loaded staff cost of $120 an hour, and you burn $36,000 a year in manual fixes to clean up after an unconfigured tool.

That purchase adds a subscription to ongoing manual labor without fixing the underlying process.

What breaks first

When software deployments stall, it is rarely because the core software broke. It breaks at three operational seams: missing API permissions when source systems change, unowned edge cases where human overrides disappear under load, and unpriced maintenance hours when the internal team member who built the integration leaves.

The filter before you fund anything

Before approving any software purchase or vendor add-on, run every proposal through four checks:

First, test existing functionality. Ask your platform owner to build the required output using software you already pay for. If the current stack solves the problem, stop there.

Second, run a bounded internal test if a real gap exists. Give your team a tight requirement and a strict deadline. Make them show a working result alongside the exact engineering, hosting, and support effort needed to maintain it.

Fund the test separately from any go-live decision, because a prototype that works once is not an enterprise system......

Third, isolate cash outlays from internal hours. Keep vendor fees and staff time in separate ledger totals. Claim a payroll saving only when staffing, overtime, or a planned hire changes.

Released hours represent operational capacity, not cash in the bank!

Finally, establish named business ownership. Specify who prepares data, verifies output, and resolves errors after launch.

Keep authority over your product knowledge and service standards inside your own team, even when delegating technical work to a partner.

Hear how Rudi chose

In the full Build vs Buy episode, Rudi explains why Fisher & Paykel bought its service agent and how he assessed the partner through the changes that followed. Listen around 12:25 for the work on the agent and data, and the questions he uses to judge whether the partnership is working. Use them to ask your supplier how it handles problems after implementation

Watch below or listen on Apple Podcasts or Spotify.

Copy to your supplier

Copy to your supplier

Subject: [Feature] quote: result, responsibilities and full cost

Before we approve this quote, please confirm:

1. Can you demonstrate [required result] using agreed test records, including a failed run and recovery?
2. Which setup, data preparation and integration tasks are included? Which tasks will our team perform?
3. Who detects failures, restores service and updates the connection when the source system changes? What response commitments and exclusions apply?
4. What will we pay for implementation and the first 12 months of licences, usage and support? Show assumptions, variable charges and work priced separately.

Please identify where these commitments appear in the quote or agreement. Where something remains untested or unpriced, mark it as unknown.

Write the approval brief

Use the supplier's reply and the comparison sheet to complete this page. Mark unsupported fields unknown and name who will resolve them. Whoever approves the spend needs to see why you chose the option and what evidence would change the decision.

Decision requested: [Configure / buy / fund a bounded internal test / hold]

Required result and evidence: [What must happen; what the test demonstrated; any limitation.]

First-year cash: [Setup plus 12 months of licences, hosting, usage and external support. Separate quoted prices from estimates.]

Internal staff time: [Setup, checking and maintenance hours; named roles; work displaced.]

Supplier responsibilities: [Deliverables, support commitments and exclusions, with quote or contract references.]

Our responsibilities: [Data, business rules, approvals, checking and backup owner, as applicable.]

Reason for this option: [Why it meets our requirement better than the other available options, considering cash, capacity and service.]

Condition before approval: [Missing evidence or a failed test that could change the decision; owner and due date.]

Review: [Accountable owner, review date and the result that would make us stop or change course.]

Copy the supplier request and approval brief above, and save the comparison sheet for your review.

Before Friday, choose one optional quote and give the process owner and the person responsible for support 48 hours for an initial review. Set a limit on the hours they spend, and ask them to challenge your preferred option. At the end of the review, require the completed brief, including an owner and due date for each outstanding answer or test.

What are we paying the supplier to take responsibility for?

Until next time, Ramon

---

About Applied AI Australia

Applied AI Australia helps executives turn AI into measurable business outcomes. We filter every initiative through one question: Does this increase revenue or decrease costs? If not, it's noise.

I am an executive who advises, not a career consultant. After carrying the P&L at News Corp, I built Applied AI Australia because I kept seeing smart executives sold vague AI strategies that never touched the P&L.

Following our acquisition by Acquire Intelligence, we combine this approach with a 9,500-person global business that delivers enterprise execution.

Staying up to date with AI is hard, so we publish a regular podcast and weekly newsletter to give busy executives the judgment they need in less than an hour a week.

Listen on Spotify or Apple Podcasts.

Disclaimer: Nothing in this newsletter is legal, financial, or professional advice. It is research, pattern recognition, and practical operating observations for Australian boards and executives. Before acting on any of it, speak with your own adviser.