Should you build or buy your next piece of software?

AI has changed the build-versus-buy conversation.

Not long ago, building internal software meant weeks of scoping, engineering tradeoffs, roadmap debates, and maintenance commitments. Today, a small team can prototype a workflow in a day. A product manager can automate a repetitive task. An operations team can connect a few tools and create something that would’ve previously needed a dedicated project.

That’s a real shift and it should change how companies think about software. What it shouldn’t lead to is the conclusion that everything should be built internally.

The right question is no longer “can we build this?” Increasingly, the answer is yes. The question now is increasingly becoming “is this something we need to own?”

That distinction matters for a whole range of reasons. Building a functioning prototype that delivers an incredible demo is cheaper than ever, but it does not reveal the real costs that still exist in maintaining internal tooling, the long tail of features and functionality required to roll something out to hundreds, and even thousands of people, or the opportunity cost of spending your tokens in one place over another. AI has made the first version cheaper, not the full system.

The next phase of software won’t be defined by companies building everything or buying everything. It’ll be defined by better judgment about where ownership actually matters.

Throughout the rest of this article, I set out the considerations that are relevant to the question ‘should we build this ourselves’, even in a world where doing that is a distinct possibility.

Build where your opinion creates advantage

The strongest case for building is when the workflow expresses something specific about how your company wins.

A bank may have a distinct view on risk. A logistics company may have a proprietary way to route drivers. A marketplace may need a fraud model shaped by its own supply, demand, and trust dynamics. In those cases, the internal system isn’t just software. Building your own solution is a real way to encode your company’s unique perspective on a problem that makes it more likely you will succeed.

That’s different from building software because it’s now technically possible. A company that makes tractors probably won’t have an opinion on how payroll software should work that creates a unique advantage in their market. Nor will a healthcare provider be more likely to win if they spend time building their own contract management system.

Ultimately, the strategic version of build versus buy starts at the company level. Does this system reflect how we win, or is it a necessary function we simply need to run well? If the workflow carries your company’s unique judgment, building may be worth it. If the workflow is important but not differentiating, buying is often the more disciplined choice.

Sometimes the narrow wedge is enough

AI also makes building more attractive when the software you’d otherwise buy is much larger than the job you need done. Many SaaS platforms have expanded to meet such a deep set of requirements for their largest customers, that the surface area of their product is incredibly broad. That breadth can be useful if you need the full system. It can equally be expensive noise if you only need one narrow wedge to meet your requirements.

Imagine a finance team that needs to turn recurring vendor invoices into a weekly accruals checklist. The team doesn’t need a full procurement suite, a new ERP workflow, or a quarter-long implementation. It needs one repeatable workflow that reads the same files, flags the same exceptions, and produces a format the controller already trusts.

That kind of tool is a good candidate to build. It’s narrow. It’s close to the work. The risk is contained. The people who need it can shape it quickly.

Broad platforms still have a place, but unused capability still has a cost. People have to learn it, evaluate it, administer it, and work around it. If a platform gives you ten times more workflow than your team will use, building the small piece you actually need may be simpler and more useful.

A good internal AI tool usually starts small. It does one job. It solves a known problem. It doesn’t try to become a platform on day one.

Count the cost after the demo

The easiest mistake is to compare the price of a vendor with the cost of building a demo.

That comparison is almost always wrong.

A demo doesn’t need onboarding. It doesn’t need support. It doesn’t need audit logs, access controls, documentation, user education, uptime commitments, or a roadmap. It doesn’t need to handle the edge cases that only appear once more than one team starts depending on it.

Internal tools also need owners. Someone has to improve the experience, fix the workflow when it breaks, adjust prompts when model behavior changes, update integrations when APIs move, and answer questions when the output looks wrong.

That’s maintenance cost. The cost of keeping a tool useful after the first version ships.

The other cost teams need to consider is opportunity cost. Every minute your team spends building internal tooling is a minute they aren’t spending working on customer problems, strategic product work, revenue opportunities, or internal systems that are more central to how the business wins. One person we heard from on the topic shared that “our business has an incredibly hands on B2B sales and post-sales implementation process. Every minute we aren’t spending building relationships and working with our customers is incredibly costly.”

In the market today, this is increasingly becoming the most important question. Not “can we build it?” but “is this the best thing for these people to spend their attention on?”

To share another example, a sales leader can probably build a basic research platform for account planning. The better question is whether that’s a better use of their time than coaching reps, talking to customers, or improving the sales motion. Where you spend your time (and increasingly where you spend your tokens), has a real opportunity cost.

Buy when a vendor’s opinion is worth more than developing your own

When you buy software, you’re not just buying features. You’re buying someone’s opinion about how a problem should be solved.

That opinion has a cost to develop. A specialist vendor has spent years learning the shape of the problem: the edge cases, the defaults, the permissions model, the moments where teams get stuck, and the parts that look simple until they’re used at scale.

That cost is spread across an entire customer base. The vendor can invest more deeply in the problem because many companies are paying for the same learning. For one company to recreate that depth internally, they need to carefully consider whether it’s worth investing the time required developing that level of judgment.

Sometimes it is. If your company has a sharper view than the market, build around it.

Often it isn’t. In deep verticals like legal, finance, security, healthcare, support, and customer intelligence, the workflow you see is rarely the whole problem. Buying can be the more efficient way to inherit years of focused thinking. One publicly traded company we heard from recently shared this anecdote: “we bought an AI customer service platform because we knew that their team has thought about the underlying workflows, the right data structures, and the UX patterns much more deeply than we ever could, and we get to benefit from that level of expertise.”

Buy when it raises the standard

There’s also a second-order benefit that can go under appreciated: excellent products teach teams what good looks like.

A good vendor becomes a reference point. It shows how the workflow is structured, what the defaults are, which edge cases matter, and how expert teams think about the problem. That can sharpen taste inside your company. It can help people see the difference between a workflow that technically functions and one shaped by years of focus.

That learning has value. Sometimes a team buys first, learns the shape of the problem, and later builds once it has a stronger internal point of view.

Buy when risk needs an owner

When you build internally, you concentrate responsibility. Your company owns uptime, security, compliance, maintenance, incident response, and every failure mode the system creates.

That may be fine for a low-risk internal workflow. A lightweight agent that drafts weekly team updates can break without much consequence. But, a system that touches regulated data, customer commitments, revenue processes, or product strategy has a higher bar.

A vendor contract doesn’t remove risk. It changes where some of that responsibility sits.

It buys you accountability and gives you recourse when you need it. It gives you a team whose job is to keep the system secure, available, documented, and current. Going further, it also provides legal, security, and procurement teams something concrete to evaluate. Ultimately, it gives you someone to call when things go wrong.

For an early-stage startup, that may not matter much. Speed may matter more. For a large enterprise, it can matter a lot.

The larger the organization, the more software decisions become risk decisions. Buying isn’t only about capability. Sometimes it’s about knowing who owns the problem when the stakes are high.

Customer intelligence shows the difference

Customer intelligence shows how quickly a simple build-versus-buy question can become a deeper infrastructure decision.

Imagine a product team that wants faster access to customer feedback. At first, building looks obvious. Connect an LLM to a folder of research notes. Summarize interviews. Ask a few questions. Generate a weekly report. For one team and one data source, that may be enough.

But the moment the company wants customer understanding to shape roadmap decisions, the job gets wider. The system has to connect signals from interviews, support tickets, sales calls, surveys, app reviews, and product feedback. It has to preserve history, respect permissions, cite the evidence behind every answer, and give product, research, design, support, sales, and leadership a shared view of what customers are saying.

Without that shared layer, AI can make fragmentation worse. Product gets one answer from research notes. Support sees another pattern in tickets. Sales hears something different in calls. Leadership gets a biased summary that can’t be traced back to evidence.

In this version of the world, you end up with more outputs and less trust. We see this pattern often with many of the companies we work closely with. The problem is rarely that they lack customer data. To the contrary, they have more of it than ever. The problem is that those signals are scattered, interpreted differently, and disconnected from the decisions they should inform.

This is the problem Dovetail is built for: an AI-native Customer Intelligence Platform that brings customer signals into one system of record, turns them into decision-ready intelligence, and makes that context accessible across the organization. Teams get the shared history, governance, collaboration, and always-on workflows they need to make customer intelligence useful at scale.

At small scale, a bot can help. At company scale, customer intelligence becomes infrastructure.

A practical framework for build versus buy

The decision should ultimately start with ownership. If a system reflects how your company wins, it may be worth building. If it demands depth, trust, or accountability that already exists elsewhere, buying may be the wiser move. We’ve pulled together a practical framework to help you think through this decision:

• Core advantage: Does this system express how our company wins? Build when the answer is yes. Buy when the function matters but isn’t differentiating.
• Distinct opinion: Do we have a better view than the market? Build when your internal judgment is sharper. Buy when a specialist’s accumulated learning is stronger than yours.
• Scope: Do we need the whole system, or just one narrow wedge? Build when bought software is mostly unused surface area. Buy when the depth of the full system matters.
• Maintenance: Who owns this after the demo? Build when there’s a clear owner for quality, support, security, and iteration. Buy when that ownership would become a distraction.
• Opportunity cost: What would these people do instead? Build when the return is worth pulling talent away from other work. Buy when the same attention is better spent closer to customers, product, or revenue.
• Learning value: Would buying teach us what great looks like? Buy when the product raises your team’s standard. Build later if you develop a stronger internal point of view.
• Risk: What happens if this fails? Build when the stakes are contained. Buy when accountability, recourse, compliance, or availability matter.

The future is not build or buy. It’s both.

AI will lead companies to build more software internally. That’s inevitable, and in many cases, useful.

It’ll also make trusted platforms more important. As more workflows become automated and more teams rely on AI-generated outputs, companies will need durable systems underneath them: systems that hold context, enforce standards, and give people confidence in the answers they receive.

The pattern is already familiar. Companies buy Snowflake not because they could never assemble data infrastructure, but because standardizing data across the business is a deeper problem than storage. They buy Stripe because payments are full of edge cases most companies shouldn’t absorb themselves. They buy Notion because knowledge work is more useful when docs, projects, and context live in one shared workspace.

Customer intelligence is moving in the same direction. As AI makes product development faster, the harder problem shifts upstream: knowing what customers need, which signals to trust, and which decisions deserve action. That kind of context can’t live in scattered summaries and one-off bots. It needs a system that compounds over time.

The companies that navigate this well won’t be the ones that build everything. They’ll be the ones that know what to own.

Build where your process is a source of advantage. Build when the job is narrow and the bought version is mostly surface area you won’t use. Buy when the problem has more depth than the workflow shows. Buy when trust, context, accountability, or shared understanding matter more than control.

When everything is easier to build, judgment is what matters.