Cases from the MBA and the Vanguard · MBA module — a startup deciding whether to buy AI capability or build it
Subtitle: When a startup must decide whether to buy AI capability or build it itself
We have already launched an AI-powered platform designed to help smallholder farmers turn raw farm data into actionable insights.
The platform collects information from farmers about their farms, crops, soil, farming practices, and field conditions. That information can then be processed and translated into insights that are easier for farmers to understand and act on.
The product is now beyond the prototype stage. We have something that works, farmers are being onboarded, and we are beginning to learn what it takes to operate the system in the real world.
That has created a new problem.
The question is no longer whether we can build an AI-powered agricultural platform. We have done that.
The question is who should provide the intelligence behind it as we scale?
We currently have the option of working with an external technology and data partner. Their solution offers specialized capabilities for processing and interpreting the information that flows through our platform. It could potentially give us access to a more mature technical system without requiring us to build every component ourselves.
But it comes at a significant cost.
That cost matters because we are still operating at a stage where every major recurring expense has an opportunity cost. Money spent on the external AI capability is money that cannot be spent elsewhere: onboarding farmers, improving the product, collecting better data, expanding the team, or reaching new markets.
There is also a longer-term strategic question.
If the most important part of our platform, turning farm data into useful intelligence, is dependent on an external partner, how much of our core technology do we actually control?
The alternative is to build the intelligence layer ourselves.
Our team can develop an internal system using Python and Gemini as the underlying AI framework. This approach would be significantly more cost-effective and would give us greater control over the architecture, data flows, prompts, business rules, and future development of the platform.
It would also allow us to build around our specific data rather than relying entirely on a generalized external solution.
But cheaper does not automatically mean better.
The concern is whether an internally developed system can consistently produce insights at the quality and reliability we need. Gemini gives us a powerful underlying model, but the model itself is only one part of the system. We would still have to design the data pipeline, build the logic around the model, manage context, validate outputs, handle edge cases, and establish safeguards against incorrect or misleading recommendations.
That creates a difficult trade-off.
The external partner may give us stronger capabilities today, but we would be paying for them continuously and becoming more dependent on an outside organization.
Building internally could substantially reduce our costs and give us ownership of a critical capability, but we would also be taking responsibility for the system's performance.
The stakes are higher because this is not an internal analytics tool.
The outputs are intended for farmers.
If the system interprets a farmer's data incorrectly, gives an inappropriate recommendation, or presents an uncertain conclusion as if it were certain, the consequences could extend beyond a technical error. A farmer may spend money based on the recommendation, change a farming practice, or make a decision about their crop because they trust the platform.
At the same time, waiting for a theoretically perfect system is not realistic.
We need to improve the product while it is already being used. We need to learn from real data and real farmers. The external solution could help us move faster, but its cost could become a constraint as our user base grows.
The internal solution could be much more sustainable financially, but we would have to invest our own time and technical resources into proving that it is good enough.
There is also a temptation to treat the decision as purely technical.
We could compare accuracy, speed, cost per analysis, and reliability and choose whichever performs better.
But the decision is bigger than that.
We are deciding what kind of company we want to build.
Do we want to own the technology that sits at the centre of our product, even if that means accepting more responsibility and technical risk? Or should we focus on our core agricultural and data capabilities and allow specialized partners to provide parts of the technology?
There is no obvious answer.
An external partner could allow us to concentrate on farmers, data collection, partnerships, and market development while someone else carries part of the technical burden.
Building internally could create a capability that becomes strategically valuable over time. It could reduce our long-term costs, allow us to customize the system around our accumulated agricultural data, and reduce our dependence on another company.
But that future value is not guaranteed.
We now have to decide whether the savings and control of building internally justify the uncertainty of developing and validating the system ourselves.
The decision is particularly difficult because both options can be defended as responsible.
One argument says that when the system affects real farmers, we should pay for the strongest capability available and minimize technical risk.
The other says that a startup cannot build a sustainable business around an AI system whose underlying costs and capabilities it does not control.
Begin by asking participants which risk they would rather carry: the financial and strategic dependency risk of the external partner, or the technical and operational risk of building internally.
Do not immediately allow the group to solve the problem with "do both." The purpose is to expose what each participant considers the organization's most important constraint.
Then introduce the fact that the platform is already live. This changes the discussion: the organization is not making a theoretical technology decision. It is deciding how to evolve a system that real users already depend on.
A key fact that could change someone's position is evidence from controlled testing showing that the internally built system performs comparably to the external solution at a fraction of the cost. Conversely, evidence of materially different output quality on real farmer cases could justify continuing with the external partner.
An AI agent could help us make this decision by continuously testing both approaches against the same real-world cases. It could compare outputs, identify inconsistencies, measure accuracy against validated agricultural outcomes, track cost per farmer or analysis, monitor response times, and flag cases where either system produces an uncertain or potentially harmful recommendation. It could also model how costs would change as the number of farmers increases.
However, the AI should not make the final decision about which system becomes the company's core infrastructure. It can provide evidence and even recommend a path, but humans should retain responsibility for deciding how much financial dependency, technical risk, and farmer-facing risk the organization is willing to accept. The agent should stop and request human approval before changing the production AI engine, signing or terminating an external partnership, or allowing a new model to provide recommendations to farmers without an agreed validation threshold.
We have already built the product. Now we have to decide how much of the intelligence behind it we are willing to own.
A question for the table, a disagreement, what you would have done. The case lead reads every comment; the ones the table takes up enter the chapter as questions from the room, with your name.