Build, Buy Or Partner

Three Routes To A Capability

Once you know a use case and its data, you must decide how to get the capability. Build means your own team creates the solution. Buy means you license a finished product. Partner means an outside firm helps you design, build or run something, often with a shared outcome. Most companies use all three, for different use cases. The skill is to match the route to the situation.

A helpful rule is to build only where the work gives you an advantage that competitors cannot copy, such as a process that rests on your unique data or expertise. For common functions such as meeting notes, email drafting or invoice reading, buying is usually faster and cheaper than building. Partnering fits when you lack skills today and want to learn while delivering. Week 2's brief tells you which situation you are in.

Types Of Vendors

The market looks crowded, but it falls into a few types. Embedded AI means a product you already use adds AI features, such as your office suite, CRM or helpdesk. Specialist applications focus on one job, such as contract review or sales call analysis. Model providers sell access to foundation models through an application programming interface (API), which is a way for software to send a request and receive an answer. Cloud platforms offer models, storage and tools in one place. Integrators and consultancies design and connect solutions.

Each type fits different needs. Embedded features are the easiest start because users, security reviews and contracts already exist. Specialist applications deliver quickly in their niche. Model APIs give flexibility to teams who can build. Cloud platforms suit organizations already committed to one cloud. Integrators add capacity and experience, but you must ensure that knowledge stays with your people at the end.

Foundation Models

A foundation model is a large model trained on broad data that can be adapted to many tasks. Large language models are the best known. A company rarely trains one from scratch, since training takes huge computing power and specialist teams. Instead it uses an existing model in one of three ways: prompting it with good instructions, giving it your documents through retrieval (week 3), or fine-tuning it, which means training it further on examples from your domain.

Models differ in size, speed, cost and skill. Larger models usually handle harder reasoning and longer material, while smaller models answer faster and cost less. Many solutions route simple requests to a small model and difficult ones to a large model. Providers charge by usage, often in tokens, which are small pieces of text such as parts of words. A long document sent to a model costs more than a short question. Keep this in mind when you estimate cost.

Open And Closed Models

A closed model is available only through the provider's service. You send data in, you get answers back, and you cannot see or change the model. An open-weight model is one whose trained parameters, called weights, are published so you can download and run them on your own servers or cloud account. Licenses vary: some allow commercial use freely, others restrict it, so read the terms. The word 'open' does not always mean that the training data or code are public.

The trade-offs are practical. Closed models are often the most capable and need little setup, but your data travels to the provider and prices or terms can change. Open-weight models give you control over where data stays, the ability to adapt them, and stable behavior, but you need people and hardware to run them securely. For sensitive data or strict regulation, running a model inside your own environment is attractive. For speed to first result, a closed API usually wins. Many companies mix both.

Total Cost Of Ownership

The price on the vendor's page is only one line. Total cost of ownership (TCO) adds everything needed to run the solution for several years. A three-year view is a good habit. Count licenses or usage fees, integration with your systems, data preparation, security and legal review, training and support for users, monitoring and maintenance, and the time of your own staff. Add the cost of exit, which is how much effort it would take to move away.

Compare routes on the same basis. A built solution has high upfront and ongoing people costs but may have low usage fees. A bought product has low upfront cost and recurring fees that grow with users or volume. Ask for pricing at your expected volume, not the demo volume, and ask what happens to the price at twice that volume. Week 9 returns to running costs and return on investment in more detail. For now, the habit to build is listing every cost line before choosing.

Lock-In And How To Reduce It

Lock-in means that switching away becomes too costly or slow. It comes from several sources: your data stored in a vendor's format, workflows and prompts written for one model, staff trained on one interface, and contract terms with long commitments. Some lock-in is acceptable when the benefit is large, but it should be chosen, not discovered later.

You can reduce it with simple steps. Keep your own copies of your data and outputs in open formats. Place a thin layer between your applications and the model, so that changing the model requires changing one component. Test a second provider on a sample of your real tasks, so that a fallback exists. Negotiate contract terms: data export rights, a clear statement that your data is not used to train the vendor's models without permission, notice before price changes, and reasonable exit periods. Week 5 covers the privacy side of these terms.

A Decision Method And Questions For Vendors

Put the decision in a table. Rows are the options, such as an embedded feature, a specialist application, a model API with your own build, and a partner-led project. Columns are fit to the use case, time to first result, data and security fit, three-year TCO, lock-in, and skills needed. Score each cell and discuss the gaps. The goal is a clear reason you can explain to a manager, not a perfect formula.

When you speak to vendors, ask concrete questions. Where is our data stored and processed? Is it used to train your models? Which models are inside the product, and can they change without notice? How do you measure and report quality? What are the limits and prices at our volume? What certifications and audit reports can you share? How do we export our data and leave? A good vendor answers plainly. Evasive answers are information too.

Whatever you choose, plan for change. Models improve and prices move several times a year, so a choice made today is a decision to review, not a permanent commitment. Set a review date, usually every six or twelve months, and keep a short list of the alternatives you tested so that a switch, if needed, starts from evidence.

Key Terms

Build, buy, partner

Three routes to a capability: create it, license it, or co-deliver it with an outside firm.

Foundation model

A large model trained on broad data that can be adapted to many tasks.

API

A way for software to send a request to another service and receive an answer.

Token

A small piece of text, such as part of a word, used to measure model input and output and to set prices.

Fine-tuning

Training an existing model further on examples from your own domain.

Open-weight model

A model whose trained parameters are published so you can run it yourself, under a license.

Closed model

A model available only through the provider's service.

Total cost of ownership (TCO)

The full cost of running a solution over several years, including people, integration and exit.

Lock-in

A situation where switching away from a vendor becomes too costly or slow.

Exercise: Compare Three Routes For One Use Case

1. Take your top use case and list three realistic options, for example an embedded feature, a specialist product and a model API with a small build.
2. For each option list the cost lines for three years: fees, integration, data preparation, security review, training, support and staff time.
3. Estimate each line as a range and write the assumptions. Mark the lines you cannot estimate yet.
4. Score fit, time to first result, data and security fit, lock-in and skills needed from 1 to 5.
5. Write seven questions for vendors from the document and send them to at least one real vendor.
6. Add a lock-in note for each option: what would moving away require?
7. Write a half-page recommendation that a manager can read in two minutes.

Further Reading

• On the Opportunities and Risks of Foundation Models, Rishi Bommasani and colleagues, Stanford CRFM, 2021
• AI Engineering: Building Applications with Foundation Models, Chip Huyen, O'Reilly Media
• Designing Machine Learning Systems, Chip Huyen, O'Reilly Media
• Hidden Technical Debt in Machine Learning Systems, D. Sculley and colleagues, NeurIPS 2015