The Many Pitfalls of Build vs. Buy
It’s one of the age-old dilemmas of product development: you’ve identified an important use case that requires a new piece of functionality — do you and your team try to build it yourselves, spending precious weeks or months reinventing software someone else has been iterating on for years, or do you look externally, for a vendor (or partner), knowing that you’re hitching your success to another company and possibly resigning that part of your road map to commodity status.
To build or not to build. The Shakespearean question that every tech team eventually grapples with. Nowhere is it more relevant than in healthcare where many companies have embraced a vendor-first approach. It is an industry where data flows slowly, encumbered by privacy concerns and outdated infrastructure. Where for certain types of functionality, the vendor options, at least until recently, have been fairly limited because of the hurdle of HIPAA compliance.
At Oscar, one of our mantras is to “own the stack.” For data to be accessed instantly across all of our systems, a requirement for real-time intervention, and for us to offer much-needed cohesion in an otherwise fragmented patient journey, there are some things we simply can’t afford to let others do for us. In other words, we’ve chosen to invest in the tech we view as essential to the seamless, scalable experience we’ve set out to create.
But we don’t make these decisions lightly nor do we default to building everything in-house. As of the writing of this post, Oscar has hundreds of integrations and 50+ technology vendors. Meanwhile, we’ve built our own messaging service and clients, our own A/B testing framework, our own claims processing and UM software, eligibility, billing, provider data, and benefits configuration infrastructure, tools for sending targeted and automated communications with dynamic content, our own telemedicine platform, and our own UI component library — to name a few.
Through all of this work, we’ve learned a lot of hard lessons and we’ve developed a few heuristics we use to guide our build vs. buy decision-making:
1. There is no such thing as just buying. Nearly every vendor comes with an implementation cost and a cost to maintain your integration with them. This cost can be very significant, as anyone who has ever led a call center management or CRM rollout can attest to. Vendors always downplay this in the sales process, as much as they amplify their product’s benefits in their marketing materials. Build or buy, we’ve learned, can sometimes be a false choice — more often than not, you’re actually deciding between “build & maintain” or “buy & integrate,” two options that have as many similarities as differences.
2. “Build” estimates are often optimistic. Just as using a vendor can be more than you bargained for, building has its own hidden costs. People tend to think that what other companies have built will be straightforward to replicate, a cousin of the fallacy that “my job is hard, their job is easy.” It’s true that in many cases the vendors you’re considering have to worry about stuff that you don’t. They need a sales team to onboard their customers. They need a customer service team to answer questions about their product. They need a billing system to process platform fees. All of this comes with a technology investment that you have likely already absorbed in your own go-to-market efforts. In other words, when you choose to build instead of buy, you are in-housing the half of a vendor that is their product, and leaving behind the half that is their business model. But half of a mature technology vendor may still be a huge amount of surface area, especially for a small start-up, and the simplicity of another company’s software often belies years of painful tinkering under the hood. Just like renovating a house, what busts your budget is not the architect’s drawings, it’s what you find when the walls come down. It may still be the right call, but add a huge buffer to your estimates for the surprises that await you.
3. Understand the vendor’s core capabilities, and stick to them if you can. Vendors want to please their customers and sometimes make promises they have a hard time keeping. If you push them to do something they’ve never done before, then you should approach the relationship as more of a partnership, and be clear-eyed about the risks that come with being the beta testers for a new offering (early start-ups can make great “vend-tners”…in a future post, we’ll talk about this and other ways that partnerships can unlock awesome opportunities!)
4. Consider your long-term goals, not just your short-term ones. If the best vendor you’ve found meets your needs now, but will become a hindrance when your needs become more complex or their pricing model will become exorbitant when you achieve scale, then it tips the scales toward building sooner. At the same time, building something in-house means maintaining it, likely for years, plus potentially committing to a road map of enhancements as the industry advances. Even if you can stomach the near-term costs, are you prepared to make the long-term commitment? (It depends on your hiring plans and company vision). If you plan to commercialize this part of your technology down the road, will using a vendor make it easier or harder to do so? (It depends in part on whether using a vendor will make it easier or harder to integrate with others and on whether the vendor has achieved economies of scale you will have a hard time replicating — see “Some solutions are simply better at scale”).
5. Always do the math before you build. There are some things that can’t (easily) be quantified — the value of investing in your brand for example — but for everything else, a simple ROI model is the place to start. What kind of return will you get and how quickly can you expect it? Payback period may be a more useful metric than NPV or IRR at a start-up where uncertainty is high and there is no shortage of ROI positive projects to work on. If the return is positive but low then stick with a vendor. Tech capacity is a scarce resource, and — in principle at least — should only be allocated to projects that could generate double, triple, quadruple the value of your investment. We plan to publish our template for this in a subsequent post so stay tuned!
6. Some solutions are simply better at scale. Vendors that can spread their costs across ten or hundred times as many users may be able to deliver a cheaper or more effective result than you could manage on your own. To give a few examples:
- The leading CRMs, for all of their implementation agita, have the gravitational pull to sustain an ecosystem of apps and plug-ins, a hard-won asset for which they charge their customers dearly. While many companies have built their own CRM-like systems, often justifiably, this is a decision that bears careful consideration, and only really makes sense for use cases that go far beyond basic email marketing and sales pipeline tracking.
- The same goes for many applications of machine learning — the larger the training data set, the more powerful the model. Between Python libraries and other open source options for the ML algorithms, and an ever-growing collection of use case specific API-based solutions, there are endless ways to avoid a lot of the upfront investment of doing it in-house. We take a DIY approach for use cases and data sets that are unique to us and where we think the solution we come up with will become a core part of our technology stack.
- Niche services that apply to a small subset of your user base such as disease management for uncommon conditions.
This is all to say that “build or buy” is a delicate art and there is no perfect strategy for all companies at all stages. The best companies stay focused on what they do best, buying what they can, negotiating hard with vendors for fair prices, building the things that will give them a competitive advantage, and pursuing partnerships that move the needle. Larger companies tend to do more on their own; smaller companies should definitely do less.
In weighing these decisions, ask yourself these questions: will what you’re considering investing in differentiate your product (where differentiation means your product is uniquely delightful and valuable to customers)? Will it address a core user need or pain point? Will it translate tangibly into revenue or a much leaner operation? Do you have the expertise or discipline to do it better than others? And will the differentiation last for, say, a year or more? If so, then building is likely the way to go. If on the other hand, a feature is peripheral to your vision, your users (customers, stakeholders, etc.) won’t really notice a difference, your competitors will be able to outpace you with a vendored approach, the investment will derail other mission-critical work, and the payoff will take longer to materialize than you can stand to wait, then buying is your best bet.
Remember, you can always build it later.
Duncan Greenberg, the VP of Product, Care & Coverage Experience, oversees Oscar’s product teams focused on digital member experience, customer service technology, virtual care platform, and automation engine.
Want to talk more tech? Send our CEO, Mario, a tweet @mariots
