Building vs. Buying

It's an age-old dilemma in product development: you've identified a critical use case that necessitates a new piece of functionality — do you and your team try to build it yourself, wasting valuable weeks or months reinventing software that someone else has been iterating on for years, or do you look externally, knowing that you're tying your success to another

There are some things we simply can't afford to let others do for us, such as allowing data to be accessed instantaneously across all of our systems, allowing for real-time intervention, and providing much-needed cohesiveness in an otherwise fragmented patient journey. To put it another way, we've chosen to invest in the technology that we believe is critical to delivering the seamless, scalable experience we've set out to deliver.But we don't take these decisions lightly, and we don't build everything in-house by default

A few heuristics to help us decide whether to build or buy:

1.There is no such thing as a one-time purchase. Almost every vendor has a setup fee as well as a fee to keep your integration up to date. Anyone who has ever led a call centre management or CRM implementation will attest to the fact that this expense can be substantial. Vendors always minimize this in the sales process, even as they exaggerate the benefits of their product in their marketing materials. We've discovered that choosing between build and buy isn't always the best option; more often than not, you're choosing between "build & maintain" and "buy & integrate," two options with almost as many similarities as differences

2.Estimates for “build” are frequently overly optimistic. Building has its own hidden expenses, just as utilizing a vendor can be more than you bargained for. People have a tendency to believe that what other organizations have constructed would be simple to duplicate, a misconception that is related to the fallacy that "my work is hard, their job is easy." It's true that the vendors you're evaluating have to deal with issues that you don't. To onboard their consumers, they require a sales team. They require a customer care team to respond to product-related inquiries. To process platform fees, they'll require a billing system. All of this requires a technological investment, which you have most likely already made in your own go-to-market strategy. To put it another way, when you opt to build rather than buy, you are bringing half of a vendor's product in-house while leaving the other half out. However, for a small start-up, 50% of a mature technology vendor may still be a large amount of surface area, and the simplicity of another company's software sometimes hides years of agonizing tinkering beneath the hood. It's not the architect's plans that blow your budget when renovating a house; it's what you find after the walls come down. It may still be the best decision, but leave plenty of room in your budget for the unexpected

3.Identify the vendor's main capabilities and, if possible, stick to them. Vendors want to impress their customers, therefore they often make promises they can't follow. If you force them to do something they've never done before, you should treat the connection more like a partnership, and be aware of the risks that come with becoming beta testers for a new product

4.Think about your long-term objectives as well as your short-term objectives. If the best vendor you've identified currently fulfills your needs but will become an impediment as your needs become more sophisticated or their price model becomes expensive as you scale, it's a good sign that you should start constructing sooner rather than later. Building something in-house, on the other hand, entails maintaining it for years and possibly committing to a road map of enhancements as the industry evolves. Are you willing to make the long-term commitment, even if you can stomach the short-term costs? (It depends on your company's hiring strategy and vision.) Will working with a vendor make it easier or harder to commercialize this element of your invention in the future? (It depends in part on whether employing a vendor makes it simpler or harder to integrate with others, as well as whether the vendor has achieved economies of scale that would be difficult to duplicate — see "Some solutions are simply superior at scale")

5.Always do the math before starting a project. Some aspects can't (easily) be measured, such as the value of investing in your brand, but for the rest, a simple ROI model is a good place to start. What type of return can you anticipate, and when can you expect it? At a start-up, where uncertainty is high and there is no shortage of ROI-positive projects to work on, payback period may be a more relevant statistic than NPV or IRR. Stick with a vendor if the return is positive but low

6.Some ideas simply work better at a larger scale. Vendors who can spread their costs across tens or hundreds of times as many users may be able to produce a more cost-effective or efficient outcome than you could achieve on your own. Here are several examples

Despite their implementation woes, the biggest CRMs have the gravitational pull to maintain an ecosystem of apps and plug-ins, a hard-won asset for which their clients pay a premium. While many businesses have justified their CRM-like systems, this is a decision that should be carefully considered, and only makes sense for use cases that go beyond basic email marketing and sales funnel tracking

The same is true for many machine learning applications: the bigger the training data set, the more powerful the model. There are countless methods to avoid a lot of the initial cost of doing it in-house, thanks to Python libraries and other open source options for ML algorithms, as well as an ever-growing collection of use case specific API-based solutions. For use cases and data sets that are unique to us, we take a DIY approach since we believe the solution we come up with will become a vital element of our technology stack

Disease management for unusual illnesses, for example, are niche services that apply to a limited subset of your customer group

All of this is to imply that deciding whether to construct or buy is a delicate art, and there is no one-size-fits-all strategy for all businesses at all phases. The strongest organizations stick to their strengths, buying what they can, negotiating hard with vendors for fair pricing, building things that will give them a competitive advantage, and pursuing strategic collaborations that move the needle. Larger businesses tend to do more on their own; smaller businesses should do far less