Build vs buy

You’re a Support leader and you’re busy all the time and everything is always too late or on fire or too late and on fire. There are a million problems to solve and each problem has a million ways to be solved, each with their own app or subscription service attached. The helpdesk requires constant reconfiguration, there’s a new SaaS you just heard about for managing your internal knowledge base, your voice of the customer program needs better tooling, and everything needs to be connected with APIs and MCPs or maybe Zaps, you forget now. Maybe there’s an app to track all of it? You’ll look it up later when you have a minute.

It’s a lot.

It’s hard to make some of these decisions, to choose the right tool for the right job at the right time. And one question that keeps coming up (either in your own deliberations or from your CEO when you talk to them about it) is whether you should build something in-house or buy an off-the-shelf product. You’ve heard the “build vs buy” question before, and it seemed like an easy decision. If the thing you need is not the thing (or at least a thing) that makes the company money, then you should buy it somewhere else. And if you can’t buy it, you should probably buy the next best thing.

At least that used to be the answer, more often than not. It used to be easy. But now it’s 2026 and everyone on your team has Claude Code or Codex or Amp or some other agentic coding harness that lets them build whatever they can imagine. It seems like the balance of that equation has changed. The answer is less straightforward when building has become more accessible.

Let’s take a look at the “build vs buy” question through a few lenses to try to pin down what has changed over the past few years and how that might affect your decisions. We’ll talk about the cost of design, the cost of development, and the cost of maintenance.

Good taste costs nothing

You have a team and you have a problem that needs to be solved. Let’s say you’re looking for a new platform for your internal knowledge base. Previously you’ve been using Google Docs to keep the team’s handbook, but it’s getting hard to sort through and even harder to keep updated. Pretty standard issue that most growing Support teams face, and there are lots of options on the market. But you think to yourself that it’s just a set of documents with text and images, how hard can it be to cobble together an internal app for the team to use?

Well, that depends. (I know, I say that a lot.) Product design is a craft, and if someone on your team is good at it, then you’ve got an advantage here. You may want to handle this like a Product team would, meeting with the users (the Support staff) to understand their pain points, document the possible ways to solve it, pilot a few options, gather more feedback, and then build the final option for production.

That’s a bunch of time-consuming work. In some cases, you’ll know exactly what you want and how it should work and you can speed through some of those steps. Small helpdesk automations and cross-system integrations are often good candidates for fast designs. For other cases, though, you’d benefit from the thinking and iterating that a more intentional design sprint pushes you through. And once you’re through that, you still might not have a finely tuned design. It could still require several iterations before landing on the product that fits the team perfectly.

And that’s the point, isn’t it? If you’re building something in-house, it really should fit the team perfectly. That’s one of the clearest benefits of building the tool yourself. It’s built for your team to solve their problems the way they want them solved. You can’t buy that kinda product-market fit off the shelf. You could use AI to jump over some of the design work, but then you probably end up with a generic product that isn’t really what you wanted.

What you can buy, though, is a shortcut to good design. The company selling the software you’re looking at already went through that design process, probably several times over. You’re buying their expertise and their iterations. It may not have 100% of the features you want, and you might not want 100% of the features it has, but it’s been through several teams already and that previous usage has sharpened all those design edges that an in-house build hasn’t imagined yet.

On the other hand, it doesn’t have your taste. The only way a product feels like yours is if it’s yours. You can’t buy that.

Build vs buy in the age of AI

Once you know what you want to build, you can get down to business. The building part. This is what most people think is the core of the “build vs buy” decision. I mean, it’s right there in the name. You’re building the thing.

In 2026, software development is more accessible than it has ever been (to people and companies who can afford the tokens). For a lot of tech companies, in particular, it seems easy to tell the Support team to build anything they need. Internal tools don’t need to be perfect; they’re not going to be seen by customers. Build it over the weekend, ship it and start using it on Monday morning. Bing bang boom.

Except maybe that “boom” is your team leaking sensitive information in the new app you just shipped to production. I’m sure your security team reviews all of your internal apps and integrations and scripts to make sure everything is safe and no personally identifiable information (PII) will be accessible where it shouldn’t be. Or maybe you have some skilled folks on your team who are trusted with that. It’s possible, but it’s still time-consuming.

That sounds like fear-mongering, I know. I monger fear on occasion. The truth is, building an app isn’t as easy as telling your LLM that you want an app. Once business data is involved, especially PII but also financial information, any code going into production should be carefully reviewed. Maybe by a human, even. There are lots of little edge cases that attackers know about that you might not. And even without malicious actors, there are lots of ways data can be exposed that you may not think to look for.

Buying products lets you pay other companies to do that work for you. They have people dedicated to making sure the software they sell you is secure and that your data is safe with them. That’s their job, so that’s where they put their time and money. Your job is to answer customer tickets and fix issues with your core product. The internal tool you made isn’t getting the same attention. But the company selling that tool? They’re giving it their full attention all the time.

Let’s not kid ourselves, though. There are lots of data leaks and security flaws in off-the-shelf products. Famously so. It’s not a guaranteed security victory to buy instead of build. You’re just trying to mitigate risks.

Zen and the art of internal tool maintenance

You thought you were done because you shipped your internal app and the team is using it? Oh my sweet summer child. Welcome to maintenance hell.

Apps go down. All the time. For all sorts of reasons. Sometiems for no reason at all! And when that happens, someone needs to fix it. Not just outages, though. Bugs pop up all the time. You work in Support, you know this. Your internal app is going to have bugs and require security updates and sometimes it’s going to be DNS because it’s always DNS and someone on your team better be good at diagnosing that.

This is usually where teams sit for a second and then think, “Yeah, no, I’m going to buy that product. This sounds awful and expensive.” And that was often the correct answer. Building the app is cheaper and faster than it used to be, but maintenance lasts forever. You pay another company money every month (sometimes hundreds or thousands or even millions of dollars) to make the app’s performance their problem. They hire people to make sure the servers are up 24/7 and that bugs are fixed quickly.

And look, just like we mentioned before, we all know that this is imperfect. The bugs keep coming and the outages are sudden and sometimes it’s DNS because it’s always DNS. But this time, maybe you pay someone else to be an expert in that so your team can focus on the problems that your company has.

The downside is that even that decision isn’t always great. This year, in particular, it seems like a lot of small companies are getting acquired or shut down, or getting acquired and then shut down. There are more products on the market than I think I’ve ever seen, but people don’t trust that they’ll all be around in ten years, or five years, or one year. Of course they won’t all be around, but will the one you buy now be around? That’s a risk you may need to consider.

It depends

Ultimately, the decision depends on a couple of factors. It depends on the scale of the internal app or tool or integration that you want to build or buy. It depends on the risk tolerance of the team and of the data involved. It depends on the criticality of the tool and what it’s used for. Some tools never see sensitive data. Some tools aren’t mission critical and can afford to go offline once in a while without ruining anything. And some teams have a lot of the design, development, and maintenance skills in-house already. It’s potentially just a cost calculation of time spent working on the tools or the queue.

But what’s this???

There is, however, a secret third option.

There is also the option to contract out the work. You can find independent contractors and dev shops and agencies who can do all of this work for you. The design, development, and even the maintenance work can all be contracted out. You could even pay an external expert to lead the design work while you do the development and mainteance in-house. That depends on what skills your team has, what skills other folks at the company have who can spend time on the project, and what you’re willing to pay for. Some contractors and agencies can be expensive, and often rightfully so.

But not all of them are outside your budget. If you ask around, you can likely find folks with the skills you need, similar taste, and rates you can afford. Just about every company I’ve worked for in the past 26 years has brought in contractors to cover the middle ground solution between BUILD and BUY. They’re buying someone else’s ability to build exactly what they want, and you can do that, too.

So…

The decision to build or buy is not always easy and it’s not getting any easier as the barriers to building have gotten lower. I think this debate has become more complicated for most teams. Based on the conversations I’m having and seeing on LinkedIn and in private Support Slack groups, I’d say a lot of Support leaders are struggling with this right now.

If you’re one of the teams struggling with the “build vs buy” decision and want to talk through your particular situation, reach out. I’d love to hear what you’re doing and help you find the solution that works for you and your team.

---

Have a comment or a response to this post? Take it to Bluesky or LinkedIn.