Build, buy or customize decisions

Jules's shortlist now has five use cases, and for each one the steering committee wants to know the same thing: should Birchline buy a finished product, customize a platform with its own data, or build something of its own? Vendors have already called. One offers a retail chatbot that is "live in two weeks". A systems integrator proposes a fully custom AI platform. Owen, now studying for the Associate Cloud Engineer exam, half-jokingly suggests building everything in-house because it would be more fun. Farah lays out the options on one page. "There is no single right answer," she says, "but there is a right question for each use case: where does our own data or process make the difference, and how much control do we need?" This lesson works through that decision.

The spectrum of options

Generative AI solutions sit on a spectrum from ready-made to fully custom. Google's materials for the Generative AI Leader exam describe the landscape in layers, from infrastructure up through models, platforms and agents to applications. An organization can enter at different layers.

Google renames products from time to time, and the exam guide published in 2026 uses current names; GCP-111 covers the portfolio and its history. The decision logic in this lesson does not depend on product names.

The decision factors

Farah lists the factors that should drive the choice. Each pushes in a direction, and the best option is the one that fits the use case's strongest needs.

Applying the factors to Birchline's shortlist

Jules and Farah walk through each shortlisted use case with the steering committee.

• Email and document help for office staff: buy. The task is the same in every company, it lives inside Gmail and Docs, and staff already have the Gemini app; Gemini for Google Workspace features will be tested with 60 people from January 2027. The work is adoption, not engineering.
• Product description drafts: customize. The value comes from Birchline's catalog, style guide and examples. A platform with grounding on the catalog and a simple review screen gives control over prompts and evaluation without training a model.
• Staff policy assistant: buy first, then decide. Gemini Enterprise's search and assistant features can ground answers in approved policy documents with permissions, which may be enough. If store staff need it inside the point-of-sale screens, a customized assistant on the platform may follow.
• Review digests: customize lightly. A scheduled job sends each product's new reviews to a model with a summarization prompt and writes the digest into the merchandising dashboard. It needs integration but no special model.
• Customer email assistant (2027): customize, and evaluate a contact-center product. It must read order data through APIs, follow refund rules and hand over to people. A contact-center suite with agent assistance features may fit better than starting from scratch; the decision will follow a side-by-side pilot.

Nothing on the list justifies building or training a model from scratch. Farah notes that this is typical: very few organizations outside AI companies and the largest enterprises train their own foundation models. The common path is to buy where the task is generic and customize where the data is unique.

Comparing total cost of ownership

Prices differ in shape: per-user licenses, usage charges, and people's time to build and run. Total cost of ownership (TCO) adds them all over a period, such as three years, so options can be compared fairly. The figures below are illustrative, not real prices, for the policy assistant.

# Illustrative three-year TCO for the staff policy assistant. Not real prices.
years = 3
users = 400                                     # store managers and supervisors

buy = {"licences": users * 6 * 12 * years,       # per user, per month (illustrative)
       "setup": 8000, "content_upkeep": 6000 * years, "admin": 4000 * years}
customize = {"usage": 3500 * years,              # model and retrieval usage per year
             "build": 45000, "content_upkeep": 6000 * years, "run": 15000 * years}

for name, costs in (("Buy", buy), ("Customize", customize)):
    total = sum(costs.values())
    print(f"{name:<10} {total:>9,.0f} over {years} years  ({total / years / users:,.0f} per user per year)")

Buy          124,400 over 3 years  (104 per user per year)
Customize    118,500 over 3 years  (99 per user per year)

With these assumptions, buying is cheaper for 400 users, mainly because the custom option carries build and run costs in people's time. If the assistant later needed to serve 3,000 store staff, the comparison would shift, because license costs grow with every user while usage costs grow with questions asked. That is why the TCO model keeps its assumptions visible: the decision can be revisited when they change. Note too that content upkeep costs the same in both options. Whoever provides the technology, Birchline must keep its policies accurate.

Running a side-by-side pilot

When the choice between options is close, a short side-by-side pilot settles it with evidence. For the customer email assistant, Birchline plans to run two candidates on the same 500 labeled historical emails from the data readiness work in lesson 5: a contact-center product configured with Birchline's policies, and a customized assistant built on the AI platform with grounding on orders and policies. Each will be scored on the same rubric for accuracy, tone and correct escalation, and each will be costed with the same TCO model. Supervisors will review the outputs without knowing which option produced them, so that brand loyalty or excitement about building something does not tilt the result.

The pilot design also tests the softer factors from the decision table. How long did each option take to set up? How easily could the team change a rule? How clear were the vendor's answers to the procurement questions? Those observations go into the decision record alongside the scores.

Revisiting decisions

A build, buy or customize decision is not permanent. Products improve, prices change and Birchline's own skills grow. The AI inventory from lesson 9 includes a review date for each system, and at each review the owner asks whether the original reasons still hold. Farah expects at least one of today's customized tools to be replaced by a product feature within two years, and at least one bought tool to be outgrown. Planning for that from the start, by keeping prompts, evaluation sets and documents portable, makes the change cheap when it comes.

Owen, for his part, gets his wish in a small way: the review digest job, a simple scheduled integration, is his first production contribution, built on the platform with a summarization prompt and a few dozen lines of code. It is not a custom model, but it is his.

Questions for vendors

Buying does not hand over responsibility. Birchline's AI procurement policy, from lesson 9, requires answers to a standard set of questions before any AI purchase.

• Is our data used to train or improve the vendor's models, and can we opt out? Where is it processed and stored?
• Which underlying models are used, how are model changes announced, and can we test before a change reaches us?
• What security testing, including red teaming, has the product had, and what certifications does the vendor hold?
• Can the product ground answers in our documents with our permissions, and does it cite sources?
• What logs and reports do we receive, and how long are they kept?
• How do we export our data and configuration if we leave?
• What happens when the product gives a harmful or wrong answer, and what support and contract terms apply?

The two-week retail chatbot vendor cannot say which model it uses or whether model changes are announced. Jules declines politely and notes it in the procurement log.

Avoiding lock-in where it matters

Lock-in means switching providers would be costly or slow. Some lock-in is acceptable in exchange for speed and simplicity. Where it matters, a few habits keep options open: keeping prompts, evaluation sets and grounding documents as the organization's own assets in its own repositories; using platforms that offer a choice of models, such as Google's Model Garden, which includes Google's own models and third-party and open models; separating business logic from the model call so the model can be replaced; and testing a second model occasionally against the evaluation set. Farah's view is that the most valuable thing Birchline will own is not any model, but its curated data, its evaluation sets and its review processes, because those carry over to whatever tools come next.

Choosing a model within an option

When a use case is customized on a platform, there is still a choice of model. The exam guide lists the factors leaders should weigh: the modality needed, such as text, images or audio; the context window, which limits how much input fits at once; performance on the task, measured on the organization's own evaluation set; cost and speed; security and availability in the needed regions; and how much customization the model supports. A smaller, faster model often handles a narrow task such as tagging emails well and cheaply, while a larger model may be needed for complex reasoning across long documents. Farah's habit is to try the smallest model that meets the quality bar on Birchline's own test cases.