When buying the AI tool makes sense

I like building, and I want teams to experiment with AI. Building a small tool can help people understand a problem well enough to decide what they need. Sometimes they'll discover that a product they can buy would do the job. They may still want to finish their own version, especially if colleagues have started using it. Before they do, it's worth asking who will support it and what else those people could be working on.

Take an account research tool. The first version might work for a few sellers, but getting it ready for the whole team could require connections to more systems, access controls and a way to report incorrect briefs. If a vendor already handles much of that work, buying could save the team months of development. The comparison needs to include the work left to do, even when the prototype is already useful.

Model costs can also add up before the tool is ready. Testing prompts and rerunning failed attempts use tokens, and those costs continue when people start using the tool. For account research, comparing the cost of a generated brief with a subscription price would miss the time sellers spend checking and correcting it. Both options need to be tested on the same accounts. A cheaper tool may save very little if sellers have to redo much of the research.

The vendor's price may leave things out too. Setup fees and usage limits can change the bill, and the team may still have to build connections to its own systems. I'd want to know what a year of use would cost at the volume the team expects, including the people needed to run it. For an internal build, that means counting the builder's time even if their salary is already in the budget.

A RevOps employee building the research tool has less time to fix lead routing. Buying could free them up to do that work. This matters even if they enjoy building and are good at it. Their manager has to decide how much time they can spend on the tool without falling behind on the work the team is responsible for. A vendor's implementation team could be useful here, provided it can take on work that would otherwise fall to the same employees.

There are good reasons to build. An account recommendation might need to reflect which customers the company has the capacity to onboard, using information a vendor's product can't work with. That could justify custom development. But if the problem is that every region uses a different account review format, agreeing on a common format might let the team use an existing product. I'd check what can be configured before assuming the whole tool needs to be built internally.

Getting people to use the tool takes time as well. A customer success manager may need help deciding what to do when it flags an account as a renewal risk. Their manager needs to work out how those recommendations fit into weekly reviews. A vendor that has helped other teams through a similar rollout could be worth paying for, even if the software itself would be straightforward to build. I'd ask what help is included and who will provide it. Having a customer success manager assigned to the account doesn't tell you how much time they'll spend helping your team.

After launch, someone still has to fix broken connections and investigate answers that look wrong. If the company builds the tool, it needs to give people time to do that work after the initial project ends. Buying can reduce how much software the team maintains, although a vendor will still need help understanding problems with the company's data or business rules. A seller reporting an incorrect brief should know who to contact and what help to expect.

I'd also look at what other teams have built. If several groups are maintaining their own research tools, the company may be paying for the same work repeatedly. Buying a shared product could reduce that duplication, but only if people can use it for their jobs and stop maintaining the old tools. Otherwise, the company pays for the subscription and continues supporting the internal versions.

The team could buy a research product and add the parts that need its own data or rules. A trial would help work out how much custom work is necessary. Sellers could use both tools to prepare for calls and record what they had to correct or look up themselves. The team could then ask the vendor to demonstrate how it would handle the gaps before committing people to build those features.