AI Makes Building Easier. Should You Still Buy?

When I started using Gong in 2022, I saw it as a call recording and transcription tool. Ask most people what Gong does, and you'll probably hear the same answer. It records sales conversations, transcribes them, and helps managers coach their teams.

Useful, but there's much more to it.

Over time, I noticed people using Gong for pipeline reviews, too. Instead of relying only on information in their CRM, they were analysing actual customer conversations to understand what was happening in their deals and why.

That connected with the problem behind Gong's creation. Its co-founder, Amit Bendov, had experienced a terrible sales quarter without understanding why. The CRM data wasn't enough to explain what was happening. Customer conversations held the missing context, but listening to hundreds of hours of calls wasn't practical.

Gong set out to use AI to uncover those insights at scale. You can read more about its story on Gong's website.

What interests me most isn't the ability to record calls. It's recognising a problem that existing tools couldn't adequately solve and building a product around it.

That brings me to a question more companies are asking today:

If AI makes it easier than ever to build software, should you still buy it?

My answer is simple: sometimes you should build, sometimes you should buy. But don't make the decision based only on how quickly you can build something.

Here are three things I'd consider.

1. Can you build it, or can you solve the problem?

AI coding tools have changed software development dramatically. With the right prompts, you can generate interfaces, connect databases, build integrations, and automate workflows in a fraction of the time it once took.

I've built things this way myself, and I think it's an incredible opportunity.

It's understandable that companies are asking why they should pay for an expensive SaaS subscription when they could build something similar themselves.

But there's a difference between recreating a set of features and solving the underlying problem.

Imagine your team uses a project management tool. You know its features, understand its interface, and have identified a few things you'd like to change. With AI, you could build an alternative that addresses those frustrations.

But have you considered why the existing product works the way it does? Do you understand how different teams use it, which workflows matter, and which design decisions help people work more efficiently?

Consider a workflow that takes three minutes to complete. Could you redesign it to take just one minute?

To answer that, you need to understand why it takes three minutes in the first place, where users struggle, which steps are necessary, and which can be removed without creating new problems.

The same applies to AI. You can add AI features throughout an application, but knowing where AI will make a meaningful difference is much harder than adding a chatbot or an AI button.

Before deciding to build, ask yourself whether you understand the problem well enough to build a genuinely better solution.

2. Can you own what you build?

Getting an application to work is one thing. Keeping it secure, reliable, and useful is another.

Who will fix bugs, manage security updates, handle data privacy, meet compliance requirements, and respond when something breaks? What happens when the person who built the application leaves? Who will maintain the integrations when another system changes?

These aren't reasons to avoid building software. They're costs that belong in the decision.

A small internal tool that automates a repetitive task might be relatively easy to maintain. A system that handles payroll, employee data, or critical business processes is a very different commitment.

The consequences of failure are greater, and so are the demands around security, reliability, and compliance.

There's also an opportunity cost. Every hour your team spends maintaining an internal application is an hour it can't spend on something else.

When you buy a mature SaaS product, you're paying for more than the features you use today. You're also paying for the vendor to maintain the software, address security issues, support integrations, and continue developing the product.

That doesn't mean buying is always cheaper. SaaS subscriptions can be expensive, and vendors don't always deliver the features you need. But comparing a subscription price with the cost of generating an application is not a fair comparison.

You need to consider the total cost of ownership on both sides.

The cost of building isn't just the cost of creating the first version. It's the cost of owning it for as long as people depend on it.

3. Can you keep making it better?

This is the question I'd spend the most time thinking about.

Building a working application is becoming easier. Continuously improving it is a different challenge.

A mature product often reflects years of customer feedback, research, design decisions, and iteration. Its value isn't limited to the features it has today. It also includes the work that goes into making it better tomorrow.

Of course, established products can be bloated, expensive, and difficult to use. Buying doesn't guarantee good design. But building your own doesn't guarantee you'll do better.

Research from McKinsey offers an interesting perspective on the importance of design. Its five-year study tracked 300 publicly listed companies, analysing more than two million financial data points and 100,000 design-related actions.

Companies in the top quartile of its Design Index achieved 32 percentage points higher revenue growth and 56 percentage points higher total shareholder returns than their industry peers over the period.

The findings show an association between strong design practices and business performance, rather than proving that design alone caused the difference.

The broader lesson is that leading companies treat design as a business priority. They involve users, measure outcomes, work across teams, and continuously test their ideas.

You can read the findings in McKinsey's The Business Value of Design.

This matters when deciding whether to build or buy.

If you build your own application, who will gather feedback from users? Who will identify the next improvement? How will you know whether a change actually makes people's lives easier? And will your team have the time and expertise to keep improving the product while maintaining everything that already works?

These questions become even more important when you consider AI.

The opportunity isn't simply to add AI to an existing workflow. It's to rethink the workflow itself.

Can you eliminate unnecessary steps? Can you reduce manual work? Can you help people make better decisions? Can you make a process faster without sacrificing accuracy or control?

The technology gives you more options. Understanding which option creates the most value remains the hard part.

You might be able to recreate today's features. The bigger question is whether you can keep making the product better.

So, should you build or buy?

I'd approach the decision with a few practical questions.

• Build when the problem is specific to your business. If you have a unique workflow, a clear internal need, and the technical capability to maintain a solution, building could make sense.

• Buy when the problem is already well solved. If a mature product meets your needs, maintaining your own alternative may add complexity without creating much additional value.

• Consider the full cost. Include development, maintenance, security, compliance, integrations, support, and the time your team will spend owning the application.

• Be realistic about your ability to improve it. Think beyond the first version. Will you have the time, expertise, and feedback needed to make it better?

• Revisit the decision as your needs change. Build versus buy doesn't have to be permanent. You might buy a platform and build a small extension around it, or start with an internal tool and move to a commercial product as your requirements grow.

There isn't one right answer for every company. The important thing is to compare the alternatives based on the value they can deliver over time, not just how quickly you can get started.

The real opportunity with AI

AI has lowered the barrier to building software. More people can now turn their ideas into working applications, and businesses have more freedom to solve problems that existing products don't address well.

That's a good thing.

But the ability to build something doesn't automatically mean it's worth building. And the fact that you can recreate a product's features doesn't mean you can reproduce the value behind them.

Before you build, understand the problem. Before you buy, understand what you're paying for. And whichever route you choose, think about what it will take to keep improving the solution.

The real question isn't just whether you can build the software. It's whether building it yourself is the best way to solve the problem.