Build vs Buy in the AI Era

Posted by & filed under , , .

As AI continues to permeate every facet of software engineering, leaders are increasingly confronted with a pivotal decision: Should we build our own AI tools or buy existing solutions? This isn’t just a technical choice; it’s a strategic one that can significantly impact our teams, products, and bottom line. With the upcoming CTO ATX meetup session focusing on Build vs Buy, I thought I would chime in with a few thoughts of mine on this matter, as I see an increased anxiety on this, likely due to the high level of entropy in the ecosystem because of AI developments.

Aligning AI with Core Business Objectives

It has to be pointed out that not all AI capabilities are created equal in the context of your business, and a lot of it depends on your core business objectives: if an AI function is central to your product’s value proposition — for example a recommendation engine for an e-commerce platform, or similar — it might warrant an in-house build to maintain competitive advantage and customization. Conversely, for more generic functions like code autocompletion or anomaly detection, purchasing a ready-made solution could be more efficient and cost-effective.

In line with the above example, a recommendation engine for your e-commerce platform makes sense to be kept in-house, as it is part of the core business, while an AI-powered credit card fraud detection should be offloaded to a 3rd party.

Navigating Data Privacy and Vendor Risks

A lot of AI solutions require work on the integration side and integrating third-party AI tools often involves sharing data, some which can be of sensitive nature (think PII, credit cards etc). This raises concerns about data privacy, intellectual property protection, and compliance—especially in regulated industries. While external tools can offer rapid deployment and access to advanced features, they may also introduce risks related to data handling and vendor reliability — you are effectively putting your data in a “black box” with no idea of the level of “leakage”. It’s crucial to thoroughly assess a vendor’s data policies, security measures, and service level agreements before making a commitment.

In adtech for example we deal with large amounts of PII (Personally Identifiable Information) and AI tools are great at dealing with large amounts of data. However offloading this data to an AI tool can create a lot of legal issues if the tool doesn’t align with the regulations in this space; and the effort required to recover from these might warrant in fact an in-house approach.

Assessing Time-to-Value and Resource Allocation

Building in-house custom AI solutions demands significant time, expertise, and resources and for many organizations, this can delay the realization of value and divert focus from core product development. On the other hand, purchasing existing tools can provide immediate benefits, allowing teams to enhance productivity without the overhead of development and maintenance. However, if your organization possesses robust data science capabilities, developing bespoke solutions could offer long-term advantages through tailored functionalities.

See here the above point about the alignment with core business objectives; if a tool allows your team to add value quickly to your product without outsourcing your core business, it probably warrants thinking about a “buy” scenario.

Weighing Extensibility Against Vendor Lock-In

External AI tools may come with limitations in customization and integration, potentially leading to vendor lock-in, same as with any other 3rd party solution. While some vendors offer extensibility through APIs and plugins, these may not fully align with your evolving business needs. Building your own tools provides greater control and adaptability but requires a commitment to ongoing development and support. Carefully consider the trade-offs between flexibility and convenience in the context of your organization’s strategic goals.

Bear in mind that items “on the roadmap” are not the same as items already included in an offering by a 3rd party; roadmaps change, priorities shift and companies pivot. Keep an eye of course of the direction the 3rd party framework is going, but take into consideration what you can achieve with the current offering.

Enhancing Developer Experience and Internal Platforms

AI tools can significantly impact the developer experience and should integrate seamlessly with your existing workflows and platforms — ex: all those trivial pull requests that your team is spending time on can be probably now reviewed automatically by an AI tool. Evaluate whether a tool complements your development environment, supports your internal processes, and contributes positively to team productivity and morale. A well-integrated tool can enhance efficiency, while a poorly integrated one may lead to frustration and decreased performance.

In a recent interview, Microsoft announced about 20-30% of their code is written and reviewed by AI — that is a huge productivity boost for any team, as it allows them to concentrate their efforts on the core business code. If you can get that level of productivity boost from an AI tool, it is definitely worth considering.

Conclusion

The decision to build or buy AI tools hinges on a nuanced analysis of strategic alignment, data considerations, resource availability, and the potential impact on your development teams. As a leader, it’s imperative to weigh these factors carefully to make informed choices that align with the organization’s long-term vision and operation realities.