At a startup how do you decide what tools to build vs buy?

I run a small company that builds developer tools. Our whole business exists because our founder decided to build a thing on the side. So I'd be the last person to tell you not to build something.

But we also bootstrapped the business that grew out of that project. Stretching dollars and finding cheaper ways to do things is a core skill. I know how strong the pull can be - especially early on - to see the option that requires less upfront capital and think "maybe we can do this cheaply?"

I've spent a decent amount of time thinking about the build-vs-buy decision. Not as an abstract framework, but as a real one with real consequences every quarter.

We build BugSplat. That's our thing. But we use Stripe for payments, Instatus for our status page, and Intercom for fielding user questions. We use dozens of other paid tools every day as part of our workflow. There's also a decent amount of custom stuff in there - which is becoming slightly more common as AI tools help extend what a small team can do. But we don't build a service status tool. We don't build a payment processor. We buy those and move on.

But of course the easy cases are easy. The interesting question is: what about the things that are right on the line?

When a developer on your team is pressing you to give them free rein to build something because "nothing on the market fits our workflow," how do you evaluate that when the tradeoffs feel genuinely close?

The math is harder than it looks

Here's the thing about build-vs-buy decisions: the upfront cost of buying always feels more painful than the slow bleed of building. Writing a check for a SaaS tool hits the budget today. Assigning a developer to build something internally gets amortized across a quarter or a year - and is much easier to ignore. Behavioral economists call this loss aversion - a known cost today always feels worse than an equivalent cost spread out over time, even when the spread-out cost is bigger.

That asymmetry messes with your judgment. So you need a framework that accounts for it.

Six questions I ask every time

1. How urgent is this? Do we need it now, or do we have time to evaluate?
2. Do we have the budget to buy it today?
3. How long will it take to build - and how much ongoing maintenance will it need?
4. What does that total cost look like compared to just buying a tool?
5. How close will our homegrown version actually get to a purchased one in quality and fit?
6. How do I expect all of the above to change in a year? In three years?

I'm not claiming this is rigorous. But forcing yourself to answer all six before committing dev time will kill most bad build decisions before they start.

What I think most people find when they run through these questions honestly is that the answer is often to buy. Not because building is wrong - we're a company of builders, we love building. But because the true cost of building is almost always higher than it looks on day one, and the true cost of buying is almost always lower.

Additional Considerations

Here's what I've seen happen more than anything else: the tool just doesn't get finished. Or it gets finished, works for a while, and then rusts.

Nobody maintains it because it's not a customer-facing feature and there's always something more urgent. Six months later you're back where you started - except now you've also got a half-built internal tool to deal with. The problem you set out to fix is still there. You just spent time and money pushing it down the road.

And then there's the risk that doesn't show up in any spreadsheet.

One person builds the tool. One person understands it. That person leaves - because people leave, that's just what happens - and now you've got an undocumented system nobody can maintain. This is a risk with complicated purchased tools too, especially if only one team member knows how to use them. But at least with a tool you're paying for, there's public documentation and a support team behind it. That's part of what you're paying for.

For small teams especially, this kind of turnover can be a real setback.

Crash reporting: a case study

Crash reporting is what we know best, so we wrote a deeper dive using it as the example - the specific tradeoffs, how AI changes the calculus, what happens when there are well-supported open-source options to lean on. You can read that here. But the framework above applies to almost any tool that isn't your core product.

Final thought

If I had to TLDR this post: build the thing that is your business. Buy the rest. You'll thank me later - or at least you'll have someone else's support team to blame when something goes sideways.