Here’s why your SaaS startup should buy, not build

When I launched my startup, I was in the driving seat every minute of every day. Early on, when it was just me, my co-founders, and a stack of pizza boxes, I had ownership of every decision that got made.

It was hard to imagine taking a less hands-on approach, or delegating important decisions to others — but as the company grew I learned, as every boss must, that sharing power was the only way to succeed. 

It’s the same, in many ways, when it comes to innovation. Early on, it’s tempting to do everything internally: if your product needs a new widget, you set your R&D team loose on widget development.

That can be a smart approach, allowing you to build tools that meet your exact needs. Instead of changing your product to align with pre-existing widgets, you can design the exact widget you need for a given purpose. 

Building your own widgets also ensures you know everything there is to know about your product. You’ll never run into widget-related problems that nobody on your team understands, the theory goes, and if your needs change you’ll have in-house experts who can crank out a new generation of widgets calibrated to work perfectly with your evolving product.

The problem with building

In practice, however, a company that insists on building its own widgets is like a boss who insists on making every single decision themselves. As your company grows, your DIY ethos can hold you back by clogging your innovation pipeline and making it harder to focus on improving your core product. 

That’s something I learned the hard way. My company specializes in data storytelling, and early on our users told us they wanted data entry tools as part of the package. Makes sense, right? You can’t do data storytelling without data.

We’d assembled a crack team of data analysts and design mavens, and while we understood data we didn’t have the specialized skill-set needed to create killer data-entry tools.

We tried anyway, and burnt months of development building tools that ultimately didn’t meet our own high standards. The stuff we developed wound up getting shelved, delivering not a jot of value for our customers. All the time and engineer-hours we’d wasted along the way could have been far better spent focusing on our core value proposition. 

Now, when we identify key features that complement our core product, we make a point of looking first at the available off-the-shelf solutions. If one exists, we just buy it — and invest the time and energy we’ve saved in other, more fruitful areas of research and development.

The innovation trap

The problem is that R&D projects only ever get more complicated over time. In fact, just 2.5% of companies claim that all their development projects succeed, and one in six internal “build” projects have 200% or greater cost overruns.

As my company’s “data entry” misfire shows, building is difficult, and building something that doesn’t fall squarely within your areas of expertise is doubly so.

After all, our society only functions because we’ve learned to specialize. Building something without external help might let us reconnect with our primitive past, but it’s a lousy way to get things done.

Let’s face it: if I had to make my own shoes from scratch, I’d be wearing, at best, a single pair of ill-fitting flip-flops. Instead, because I outsource the process, I’ve got a closet full of sneakers, hiking shoes, and rain boots far better than anything I could cobble together myself. 

In the same way, companies that build everything themselves wind up reinventing the wheel, and missing out on other companies’ hard-won discoveries. That slows down innovation and growth. In fact, companies innovate almost a fifth faster when they license supporting technologies rather than developing them in-house. 

The case for buying software

The “Build v. Buy” debate is especially pertinent in the enterprise software space. Tech companies already have engineers and developers on staff, so when you need to expand your software’s capabilities, why wouldn’t you simply set your existing team on the problem?

Look closer, though, and you’ll see that software, too, is built on the successes of others. When my company uses AI tools, for instance, we assemble components from software libraries; the magic lies not in coding every line from scratch, but rather in assembling tools in the right order to create something new and powerful.

To find that sweet spot, you need to figure out what your engineers can do better than anyone else, and then maximize the time they spend doing it. But if there are areas where some other vendor can do a better job than your internal team, lean into that, and hire that vendor to improve your product.

Instead of seeing outsourcing as a failure, view it as a smart allocation of resources. You aren’t getting ripped off — you’re buying back time your engineers would otherwise have wasted building substandard features, and empowering them to use their talent where it’ll do the most good.

Move faster, stay ahead

As a founder, I’ve learned that being a jack of all trades is a shortcut to mediocrity.

Companies that build for themselves start out thinking they’ll be able to dictate product specs and ensure their solutions perfectly meet their needs — but soon find they’re constrained by design or technological decisions they made early on, and lack the resources to change direction.

By contrast, companies that buy tech can pivot simply by changing their vendor. In the SaaS era, it’s never been easier to change direction — and because vendors know that, they’ll bend over backwards to keep innovating, and give you the features that you need as your company evolves. 

Creating a great business is about figuring out what makes your business great, then executing that as well as you possibly can. When you buy instead of build, you can keep your team focused on the areas where they really shine.

This ultimately helps you grow your company, build a loyal customer base, and cement a well-earned reputation for consistent excellence. And isn’t that what it’s all about?