When an AI or automation project lands on your desk, a build vs buy software framework feels like the obvious first tool. It forces the right conversation about control, speed and cost. But it also frames the choice as a one-time verdict, and that is where AI projects tend to go wrong. The tools change quickly, the pricing changes with them, and the process you automate today may look different a year or two from now.
Treat the framework as a starting point rather than an answer. This article shows you how to define the job first, sort what to build, buy or partner on, and count the real cost. Then comes a question that rarely gets its own line in a budget: how expensive it is to change your mind later. For most small and mid-sized companies, that question matters more than the first.
Build what makes your company distinctive, buy what every company in your sector needs, and structure the arrangement so you can change it. The first two parts are familiar. The third deserves more attention because AI tooling moves faster than most software contracts run. A choice that looks sensible at signing can look awkward at renewal.
The classic trade-off is simple. Buying gives you proven capability quickly, but you accept limits on customization and control. Building reverses that: you gain control and take on the time, the cost and the upkeep. Harvard Business Review's article on rethinking build-or-buy strategy notes that buying is typically presented as a route to scale, speed-to-market and ready-to-use assets. That description is fair, although it describes the day you sign rather than the years that follow.
For AI and workflow automation, more than two options exist. You can buy a platform and build only the workflow on top of it. You can also bring in a partner to design the process while you own the result. Each variation changes your risk profile, which is why a strict two-way choice often leaves owners stuck.
Before you compare vendors or quotes, write down the job the system must do. A tool is only good or bad relative to a job. Without one, every demo looks impressive and every custom proposal looks reasonable.
Product teams use a lightweight structure for this, which First Round Review describes in its jobs-to-be-done article. The template has four parts: when I (the context), but (the barrier), help me (the goal), so I (the outcome). For an SME, it might read: when a supplier invoice arrives by email, but someone retypes it into the accounting system, help me capture the data without manual entry, so my finance lead spends time on exceptions.
Notice what the statement leaves out. It names no software, no model and no feature, because a job describes a need rather than a product. That discipline keeps you from buying a capability you never needed, or commissioning a build for a problem that a configuration setting would solve. It also gives you one sentence to hand to every vendor and developer, so you can compare their answers on equal terms.
Applying a build vs buy software framework to AI works better with three buckets than two. McKinsey's Re:think piece by Ankit Kapoor poses the question as what to build, what to buy and where to partner. It ties each answer to what a company must own to create advantage, and what it can safely rent from the market. Kapoor argues that most organizations do not need to own the underlying technology, since they can buy access to large language models, cloud infrastructure, data services and security tools from established providers.
What they should build, in his account, are the differentiating capabilities: proprietary workflows and data, governance models, institutional knowledge and customer relationships. Partnerships fit the transformation work itself, such as redesigning workflows and training employees. He adds that partnering with a software provider can beat an off-the-shelf product when you want more control over your data and ways of working.
His example is concrete. A real estate services company wanted to automate two manual finance tasks: matching customer payments to invoices, and billing. It bought foundational technology and agent tools from a cloud provider, built workflows that reflect its own business rules, and hired an external partner for implementation and change management. According to McKinsey, the company automated roughly half of its targeted workflow steps, and people still review the uncertain cases.
| Route | Best when | Main risk | Confirm before committing |
|---|---|---|---|
| Off-the-shelf tool | The process is common across your industry and a product already fits | You bend your process to the tool, and pricing and features change on the vendor's schedule | Data export, integration options, contract term, data processing terms |
| Custom build | The process is part of your edge and no product fits without compromise | Ongoing maintenance, dependence on a small team, slower start | Who owns the code and documentation, who maintains it, what happens if the team changes |
| Bought platform, built workflow | You want control of the logic without owning the underlying technology | Integration effort and split responsibility between providers | Which layer you can replace, how the workflow is documented, who is accountable when something fails |
| Partner-led | You lack in-house capacity for redesign, training and change management | Dependence on the partner's availability and approach | Handover plan, knowledge transfer, what you own at the end |
The cheapest option on day one is not always the cheapest over time, because exit costs sit outside the quote. Every decision carries a second price, the price of reversing it. That price rarely appears in a proposal or in most build vs buy software framework scorecards, so you have to ask for it.
Switching costs collect in a few predictable places. Naming them before you sign lets you weigh them against the benefit.
The first two items are the ones you control. A written description of each business rule is the most portable asset in any automation project, whether the engine underneath is bought or built. If the rules are documented, replacement becomes a migration. If they are not, it becomes a rediscovery.
The middle route has a long history. In a 1994 article in MIT Sloan Management Review, J. Debra Hofman and John Rockart described a template approach that combined favorable aspects of buying and building. A company takes an existing system and changes it at the design level for a new organization. The technology they discussed is long obsolete, but the trade-offs are not.
The authors noted that modifying a package to fit your organization, or your organization to fit the package, can be extremely difficult and costly. They also reported that Canadian Airlines allocated 1.5 maintenance staff to its template-based application, against seven on a comparable system built on a different technology. Treat that as an illustration rather than a benchmark, since it comes from one company three decades ago. It does show that upkeep, not the first build, can be where the gap accumulates.
Reversibility is a design choice, and it costs little when you make it early. Ask for data export in writing before the pilot starts. Keep a plain-language process document that the vendor or developer updates whenever the logic changes. Prefer a short initial term with renewal options, and make sure any custom workflow definitions and configuration belong to you under the agreement. Because ownership and exit terms vary by contract and jurisdiction, have a lawyer review them.
None of this means you should avoid commitment. A decision you can unwind lets you move faster, because the penalty for being wrong shrinks. It also makes a small pilot easier to approve, which is where this article goes next.
A quote covers the build or the licence. Total cost of ownership covers everything required to keep the result useful. For AI-based automation, that includes usage fees that rise with volume, integration with existing systems, process redesign, staff training, monitoring, security and privacy review, and the internal time of the people who know the work.
Whatever build vs buy software framework you use, ask each provider to break its estimate into those lines. Then compare the options over several years rather than at launch. A bought tool may look cheaper in year one, while a custom build may pay off only when volume is high and requirements are stable. Neither pattern is a rule, so test both against your own figures.
Custom systems add one more cost that rarely appears in early estimates: aging. Software you build today becomes software someone must maintain, update and eventually replace. Our article on the signs that a system has become legacy software covers how that unfolds. A well-documented build with clear ownership ages more gently than an undocumented one.
Many decisions resolve here, long before cost enters. A bought tool that cannot read your data or write back to your system of record becomes a second place to type things. Map where the information starts, where it must end and which systems it passes through. If the path crosses several systems, the integration effort may exceed the tool's price. Our guide to connecting AI to your existing business infrastructure explains the layers in plain terms.
For features, a simple priority sort helps: must have, should have, could have and won't have this time. Products usually cover the must-haves and part of the should-haves. The gap between your list and the product tells you whether to configure, extend or build. A workshop method such as Wardley mapping can show which components are commodity and which are distinctive, though a two-column list does most of that work for a small company.
AI projects depend on the quality and location of your data. Check whether the data the system needs is complete, current and accessible, and whether it contains personal information. If it does, the tool or build must meet GDPR obligations, such as a data processing agreement and a lawful basis for processing. Ask every provider in writing where data is stored and processed, and whether it uses your data to train its models. Requirements differ from case to case, so have your data protection officer or legal counsel confirm what applies to you.
Strict security and compliance requirements often point toward buying, since a mature product may already carry the certifications you need. Treat a certification as evidence that a credential is held, not as a guarantee of how the product behaves in your setup.
Even a careful build vs buy software framework cannot predict how your people and your data behave, but a pilot can. Choose one process, state the job in a sentence, and agree up front what result counts as success. Fix the time frame and the people involved. Decide in advance what you will do if the result falls short, so the pilot ends in a decision rather than an extension.
A pilot can use a bought tool even when you suspect a custom build will follow. It shows which parts of the process need your own logic and which the tool already handles, and that sharpens the build scope. It also produces the process documentation that lowers your switching cost later. If you want an outside view on which process to pilot first, Xerx AI consulting and AI potential analysis looks at where automation fits your company.
Mixed signals are normal. In that case, buy the commodity layers, build the thin layer that carries your rules, and revisit the split once the pilot reports.
Finance will ask for a range and a payback logic, not a single number. Present a low, expected and high case, state the assumptions behind each, and show the exit cost next to the price. The people who will use the result need to see their own role in it. In the McKinsey example, employees focus on oversight while agents handle repetitive, rule-based work, a framing worth borrowing if it is true for your case.
Procurement will want comparable quotes. Give each provider the same one-sentence job statement, the same must-have list and the same questions about data, ownership and exit. Differences in their answers then reflect real differences between them rather than differences in what you asked.
Write a single page with five lines: the job, the route you chose (buy, build, assemble or partner), the multi-year cost range, the exit plan, and the pilot success test. If you cannot fill a line, that is the next question to answer. A framework for build vs buy software decisions gets you to the right shortlist, while this page gets you to a decision you can defend and, if the facts change, reverse.
Most small companies start by buying or assembling, because the underlying technology is available from established providers. Building makes sense for the layer that carries your own business rules and data, especially if no product fits without bending your process.
It usually means buying a platform or foundation and building only the workflow on top, or working with a partner who designs the process while you keep ownership of the result. A 1994 MIT Sloan Management Review article described a related template approach in which an existing system is adapted at the design level.
Ask in writing about data export, who owns your workflow definitions and configuration, the minimum contract term and the cost of leaving. Keep your business rules documented in plain language so a replacement becomes a migration instead of a rediscovery. Have a lawyer review the terms.
A pilot is still worthwhile, because it tests your data, your people and your process against the tool or design before you commit the full budget. It also shows which parts need custom logic and produces documentation you can reuse.
Keep reading
A quote for a headless shop looks larger than the platform price suggests. Here is where the money goes, what founders underestimate, and when the spend pays back.
Before you budget for a shared connection layer, learn what it does, when a few direct connections are enough, and who owns the risk after launch.
Age does not make software legacy. Learn the cost-of-change test, six warning signs, four modernization routes and the data risks to weigh before you set a budget.