All companies are technology companies now. So one day, everyone will need to choose whether to build vs. buy software.
I’ve worked at technology companies long enough to see the good and bad endings of this film.
In one instance, my employer became so enamored with a legacy lead management system they kept upgrading its functionality until they almost built Salesforce. It took almost two years to realize Salesforce was better and less expensive.
At the same time at the same organization, we built a lightweight web application from scratch that yielded triple-digit ROI. It’s still the main source of the company’s inbound marketing revenue.
There are clear scenarios for when you should build vs. buy software. In the rest of this article, I’ll outline when you should make which choice based on my experience with these two projects (well that, and the consensus of other experts).
The argument for buying software is pretty obvious, and I’m not going to bullshit you: it’s what you should do in most cases. It’s easier and cheaper, and the outcomes are more reliable.
Plus you don’t even really “buy” software these days, you rent it. The software as a service model is so named because this new generation of cloud products is more like services. People use them until they don’t want them anymore, and then they stop.
Here are the most common scenarios when you should buy software:
We’re living in the golden age of SaaS products. There are more technology solutions on the market than at any time in history. If you need to solve a common business problem, chances are pretty good you can find a product that does what you need.
Plus, building good software isn’t easy. It takes time, development resources, data-informed designs, and constant iteration.
If products already exist that meet most of your requirements, then you should probably build a consideration set and find your favorite. Instead of having to enter into the labyrinth of software development, you’ll have (more or less) immediate access to the features with an off-the-shelf solution.
You probably won’t find a product that matches every single one of your requirements. But be realistic. As long as the software does most of what you need effectively, you’ll have a viable solution, which is the entire point, right?
Building software takes a long time —even for experienced practitioners. According to SOLTECH, their process for software development typically takes anywhere from a little over 4 months to 8 ½ months depending on the complexity of the project.
In my experience working at a full-stack development agency, these numbers are pretty accurate.
In contrast, buying a solution could be as quick as a few days.
The question you have to ask is: how urgently do you need to solve the problem?
In the case I mentioned earlier, my employer was solving for lead management. Too many leads were coming from the website for our legacy system to manage. The slowdown was costing us sales, which meant lost revenue.
In your case, you might need a complementary solution to something you’re building to take a product to market. To get your product to market, you need to act swiftly.
Whatever the case may be, when you don’t have time to wait, it’s wiser to buy.
This one is pretty straightforward. If you’re on a shoestring budget, or if you’re concerned about a software development project running over budget, you should just buy a SaaS solution.
The prices are scaled to appeal to businesses with all kinds of budgets. You can typically cancel at the drop of a hat.
What’s more, the total cost of ownership will be much lower. You won’t have to pay to maintain the software, the vendor will. You won’t have to hire expensive specialists to do the work, because the vendor employs them.
Obvious as this logic may seem, there are plenty of businesses that disregard it.
Take my previous employer’s lead management system (LMS). The developers built this system to organize leads generated from the company’s website. The system was serviceable, but there were still a lot of clunky parts. Prime example: salespeople had to manually assign themselves leads once they entered the system.
These issues could be overlooked for a while, but once we started to scale, the system began to buckle. Instead of looking elsewhere, leadership decided to augment the system. The thinking was “What do we have these developers for, if not to build software?”
And sure, the 12 months of labor the development team put into the system made the LMS better, but the legacy system was nowhere near as useful as an off-the-shelf CRM, like say Salesforce.
Despite a huge investment (by this company’s standards) leadership eventually decided to put the LMS out to pasture. We went with Salesforce, and the benefits were immediate.
Sales reps were assigned leads automatically, data could be managed inside of Salesforce rather than in spreadsheets, forecasting was more accurate, and integration with our marketing automation system was exponentially easier.
When you have in-house development resources, it’s tempting to feel you’re equipped to build your software solutions. And you might be. But that doesn’t mean you should.
If solutions already exist in the market, you’re just taking a longer, more expensive route to solve the problem.
I said at the top that most people should buy software rather than build it, and I mean that. Of course, there are always exceptions. It’s important to be clear about when it’s best to build a customer solution.
It makes sense to build custom software when the solution in question will supply you with an overwhelming business advantage —something you couldn’t achieve through an off-the-shelf solution.
You could realize this advantage through gains in productivity and efficiency, through new insight from data capture, or by bringing something new to the market. If the solution you need sits at the nexus of how your business operates, then building it yourself is the right decision.
Custom software is also a good idea if there’s nothing off the shelf that accomplishes what you need. This is less common, but it certainly happens.
For example, we designed and built a fleet management system for Ingram Barge, the foremost freight shipment company on the US’s inland waterways.
Ingram’s requirements were complex because the application had to work in very specific ways for their business. There wasn’t anything on the market that fit these requirements, and the value this application would deliver is huge.
So it made sense to design and build the software themselves.
Even under the right business circumstances, building the right software is a risky endeavor. Agile development practices and techniques like sprint zero have reduced the peril, so the risk is lower than in years gone by.
But best practices are only as good as the people carrying them out. If you want to build your software, you need to have experienced people in-house who know how to scope, plan, and execute the project.
And if you don’t have them in-house, you should work with an experienced agency that knows how to coordinate design, frontend, and backend development.
You’ll need talented people not only to build the software but also to maintain it. No technology maintains its utility without consistent updates.
At my old gig, there was another in-house application, a literary foil to the LMS —a Jean Valjean to the LMS’s Javert.
This software was built around the same time as the LMS, but it maintained its business value because we couldn’t replicate its functionality with an off-the-shelf solution.
We called it the Product Selection Tool (PST) because it helped recommend software solutions to website visitors. I won’t dive into the intricacies of the entire business model, but suffice it to say the PST had a huge impact on our marketing ROI.
Throughout the years I worked at this company, we made significant changes to the PST —improving the UX, optimizing its speed, etc. —and every change resulted in an uptick in value.
This is the perfect example of a custom piece of software that’s worth building. There were no prebuilt solutions, the value delivered far outweighed the total cost of ownership, and the strategy had staying power.
***
The build vs. buy debate is here to stay. Businesses will keep evolving, and so will the software solutions available for purchase. However, the circumstances that determine which choice you should make will remain relatively unchanged.
If you’re choosing between two diverging paths, whether to build something or buy it, consider the circumstances I’ve laid out here. That should make your choice a bit more clear.