“Wait…can’t we just build it ourselves?”
Every business is asking the same question. And for 78% of the leaders surveyed for the Build vs. Buy Report, building with AI is already part of the plan this year.
It isn’t surprising; many companies are rapidly maturing their AI strategy, with over a third (34%) shifting from surface usage to deeper transformation.
But for every ‘can we build it’ question asked, there’s a team like yours doing the math to answer it.
Because building with AI is so new, it might be challenging to understand when to say “yes” to a request and when to politely point the requester to a tool that already exists.
Highspot’s IT team ran a ‘DIY with AI’ experiment and, in the process, developed a framework for determining when to build and when to buy.
Here’s what they built (plus, what they would and wouldn’t build again).
The experiment: What they built
Highspot’s IT team caught onto the build-with-AI trend early. They wanted to understand what was possible, as well as what was at risk when building business-critical tools with AI.
So, they did exactly that.
The team picked a low-stakes use case: IT and HR agents that could provide answers and take action in tools like Slack, Jira, Workday, and Highspot.
Over six months, they built, learned, iterated, and built again until they had a tool that worked. They approached it as a learning exercise, and it certainly was.
“It was really exciting and easy to get to a place where the agents mostly worked,” said Keith Weaver, senior director of global IT and enterprise applications. “That was the first three weeks.
The rest of the time was like training a four-year-old, trying to make sure it repeatedly takes the
right action and that it’s really controlled.”
From initial conceptualization to ongoing maintenance, the team knows the process inside and out. Now, they bring that context to every ‘can we build it?’ request they field.
The framework: What they learned
The team has a whole host of questions to cover when considering a build:
- How will we resource it?
- How will we deploy it?
- How will we maintain it?
- How will we scale this across the organization?
- …and who will take the midnight support questions?
All of these considerations shape the decision to build or buy. But before anything else, the team asks one central question: Is this unique to us?
The “uniqueness” test
Highspot’s IT team breaks AI tool requests into two buckets:
- Generic use cases: These are the challenges every business encounters. It is more than likely that there are already tools available to solve it.
- Unique challenges: These are the problems that no one else encounters. They’re unique to your industry, market, and way of doing business. There isn’t a tool out there to solve for it.
“Is this something unique to my business that I can’t expect a vendor to build or deliver?” said Weaver. “Or is it roughly the same problem everyone else is trying to solve?”
This line of questioning matters because it helps you run an accurate cost-benefit analysis.
If you’re assessing a generic use case with a number of pre-existing tools out there, it may be more cost- and resource-effective to work with a vendor who will own ongoing maintenance and development.
If you’re looking at a unique use case that only you and maybe a handful of other businesses might need, then it may make sense to build it. The development cost, ongoing maintenance, and IT time are usually worth it for the value you get back.
“When you don’t have something unique, it likely makes sense to buy it,” said Weaver, “Then you get the power of an organization that has built that tool behind it and is pushing that tool forward faster than you can, simply because you’re just not going to hire that many engineers to do it.”
The build and buy approach
Most requests won’t fall neatly into either bucket, which is where a blended approach makes sense. Buy or connect a platform that can do the heavy lifting, then build just the thin, proprietary layer that’s unique to your business.
“If there’s an AI tool that brings all the agentic functionality I need to the forefront, why would I not leverage it?” said Weaver, “As long as I believe in the company and they have the ability to build our unique IT processes on top of it, that’s the way to go.”
Your goal is to provide the most effective tools with the most efficient resource usage.
Building every AI tool in your tech stack won’t help you achieve that goal. Neither will investing exclusively in generic platforms. What will help you is a more balanced approach.
Applications like Anthropic Claude or OpenAI ChatGPT can connect to the tools in your tech stack using MCP servers, so you can build agentic workflows atop your existing tools.
“If you have a unique process or proprietary tool, bring it into an AI tool like Claude, using its MCP capabilities with systems like Highspot or Salesforce that already give you a lot of that functionality,” said Weaver. “You expand what you had and spend your time and money on the uniqueness layer.”
Build alongside the tools you use regularly. That way, you can invest in developing the capabilities no vendor will, without reinventing systems that do their job well.
The practical cost of building
When you make the decision to build, be ready. It’s resource intensive, no matter whether you’re building with other tools or from scratch. Of course, there’s the up-front cost. But there’s more to it than that.
“Deploying is just the first step,” said Weaver. “It’s the iteration. It’s the testing. It’s continuing to deploy it. It’s maintaining it. It’s supporting it. It’s the full lifecycle of any software project.”
Teams often focus on the development and deployment phase, but that analysis rarely captures what it takes to keep the tool running and evolving as the business changes.
Highspot’s IT team experienced this firsthand. Their IT and HR agents came together quickly, but it took months of testing, iterating, and manual review before the team felt confident going live.
The process also took longer than usual because, unlike traditional software development, minor changes to the tool instructions had unintended effects on their reasoning and behavior.
“If you take a tool and change its prompt or description, then you have to do regression testing on all of the things someone could potentially prompt,” said Weaver. “That little change could lead the agentic reasoning to use that tool at the wrong places or in the wrong ways.”
One other caveat: AI vendors regularly retire old models and release new ones. Each shift can change how your tool interprets the logic it was built on. When that happens, you’re back in the testing phase and the process starts all over again.
None of this means you shouldn’t build. In certain scenarios, it may very well be the right choice for your business.
It is, however, a reminder that building can be just as resource intensive as buying. When the ‘can we build it’ question comes your way, you need to know how to weigh the costs and benefits to see whether building, buying, or blending the two will deliver the strongest ROI.
Answer “can we build it?” with confidence
When the question hits your desk, as it inevitably will, you have a framework to help you answer it. Highspot’s IT team uses it daily to manage requests and set expectations.
Build what’s unique. Buy and connect the rest. It’s how you build a custom tech stack that serves the needs of your business without straining your resources or IT capacity.
