Build vs Buy vs Partner: An AI Decision Framework for Mid-Market Asia

TL;DR

• Most build-vs-buy debates are framed wrong because they ignore the third option: partner.
• A six-question test routes each AI capability to the right path in under 20 minutes.
• The default for mid-market Asian firms (200-1,000 employees) should be partner-then-buy, not build.

Why now

The build-versus-buy debate is back. Frontier models commoditised the most expensive part of AI in 2024 and 2025. Boards in Singapore, Hong Kong, and Seoul now ask, "If GPT-class capability is one API call away, why are we paying a vendor 6x to wrap it?" That is the right question. The answer is not always "build."

Gartner forecasts that by 2027, 75% of enterprises in Asia-Pacific will operate at least one AI capability built on a frontier model API rather than a packaged AI product.[^1] That shift makes the build-buy-partner choice a quarterly decision, not a one-time architecture call.

The three options, defined

Build. Your engineers write the code, host the infrastructure, own the operations. You hold the IP and the support burden.

Buy. A vendor sells you a product. You configure, integrate, and pay subscription fees. You hold no IP and minimal operational burden.

Partner. A specialist firm builds with you, transfers the artefact and the knowledge, then steps back. You own the result. They own the methodology. Think of it as a build with seconded experts who then leave.

Most decision frameworks ignore partner. That is a mistake. For mid-market firms partner is often the lowest-risk path, because it caps your exposure to either talent gaps (build risk) or vendor lock-in (buy risk).

The six-question test

Run each AI capability through these six questions. Score 1 for each "yes."

1. Is this capability strategic differentiation, not table stakes? A claims-triage model for an insurance carrier in Tokyo is differentiation. A standard email summariser is not.

2. Do you have, or can you hire within 90 days, the engineering depth to operate it? Not just to build it. To run it on-call at 2 a.m. when it returns nonsense.

3. Is the data sensitive enough that a vendor cannot see it? Patient records, source code, M&A pipelines, customer financials. If the answer is yes, buy is harder. Build or partner with strict data controls becomes the path.

4. Will your needs evolve faster than a vendor can ship? If your product team ships weekly and the vendor ships quarterly, buy creates drag. Build or partner gives you cadence control.

5. Is the total 3-year cost of build less than 60% of the buy alternative? Be honest. Include on-call, training, rebuilds, and the engineer who quits in year two.

6. Is there an internal team that wants to own this? Reluctant ownership kills built systems. Without a willing owner, the build will rot within 18 months.

Reading the score

• 5-6 yes: Build. You have the strategic case, the team, and the data sensitivity to justify it.
• 3-4 yes: Partner. You have the strategic interest but not the in-house depth or willingness to staff long-term operations.
• 0-2 yes: Buy. The capability is undifferentiated, the vendor market is mature, and your engineers should be working on something else.

Examples from real engagements

A 700-person specialty insurer in Tokyo. Claims triage automation. Score: 5. Built in-house with seconded help for the first six months, now operated by a team of three. Annual run cost US$320,000. Avoided vendor lock-in on a category where the regulator (the FSA) requires deep auditability of model decisions.

A 350-person logistics firm in Ho Chi Minh City. Email and document classification for shipping paperwork. Score: 1. Bought an off-the-shelf product. Time to value: six weeks. Annual cost US$84,000. Building in-house would have cost US$280,000 in year one and absorbed two engineers the firm did not have.

A 480-person specialty retailer in Hong Kong. Personalisation engine for the loyalty programme. Score: 4. Partnered with a specialist firm for a 14-week build, then took ownership. Two internal engineers run it now. Year-one all-in cost US$210,000. The partner left a runbook, an evaluation harness, and four weeks of post-handover support.

Implementation playbook

How to apply the framework in the next 30 days.

1. List your top 8 AI capabilities under consideration. Use the candidate list from your most recent strategy offsite. If you do not have one, your first capability is "build the list."
2. Score each capability against the six questions. Have two stakeholders score independently. Reconcile differences in a 30-minute meeting.
3. Group capabilities by score. Build (5-6), Partner (3-4), Buy (0-2).
4. Sanity-check the build pile. If you have more than three capabilities scoring "build" simultaneously, you do not have the engineering capacity to deliver them. Pick the top two.
5. Test the buy pile against vendor maturity. If the vendor market for a capability has fewer than three viable players, downgrade to partner. The risk of vendor failure is too high.
6. Get sign-off on the partner pile from the function owner. Partner engagements only succeed when the receiving team is committed to taking ownership. No willing owner, no engagement.

Counter-arguments

"Build is always cheaper long-term." Sometimes. Only if you can recruit and retain the team for the long term. The Hays Asia Salary Guide 2025 reported that senior ML engineer turnover in Singapore was 22% in 2024.[^2] Lose the wrong person and the build is more expensive than the buy.

"Partners just take the money and leave you with brittle code." Some do. Vet partners on knowledge transfer, not on resume credentials. Ask for references where the client now operates without the partner. If they cannot produce one, walk.

"Vendors will lock us in." True if you do not negotiate. Demand exit clauses, data export rights, and term-limited pricing. The Wardley Mapping framework (Wardley, 2018) is useful here: for components in the "commodity" stage, lock-in is acceptable; for components closer to "custom" you negotiate harder.

Bottom line

The default path for mid-market Asian enterprises should be partner-then-buy, with build reserved for genuine strategic differentiation. Boards that default to build because "AI is strategic" usually end up with the worst of both worlds: vendor-grade capability at internal-team cost, with no one to operate it after the original engineers move on.

Score the capability. Match the score. Re-run the test every six months as your team and the vendor market both evolve.

Next read

• What Asian Mid-Market AI Pilots Actually Cost in 2026
• The Mentor Model: Why External AI Teams Fail Without Internal Capability Building

By Daniel Chen, Director, AI Advisory.

[^1]: Gartner, Predicts 2025: AI Engineering Maturity, December 2024. [^2]: Hays, Asia Salary Guide 2025, January 2025, p. 67.