Build your product from scratch vs buy something off the shelf and tweak: it’s a classic debate, and we’re not the first one’s to weigh in. After 9 years of guiding clients toward the right technology at the right time in their company’s development, we’ve honed a sense for how to strike the right balance when architecting a solution, and wanted to share how we approach these decisions.
Before we dive in, when is the right time to consider this question? If your company is still evaluating product-market fit, then it’s almost certainly too early to invest in a custom scalable solution. Don’t take our word for it. Lean Startup experts like Ash Maurya and early-stage investors like First Round Capital push for validation before investing in features. Of course, there will be exceptions, but those are few and far between among our clients.
Once you know your business goals, your use case, and your users, stakeholders, and customers, investing in your product begins to make more sense. Whether you’re breaking into a new market or scaling up to meet burgeoning demand, this is the moment to examine the potential benefits of investing in custom development along with off-the-shelf solutions.
We like to approach new clients with questions about their go-to-market strategy or scaling strategy as we wade into the build vs buy decisions. I say decisions plural because an effective product design doesn’t rely solely on scratch-made components or a store-bought codebase. The trick is evaluating which elements or components of your product should you buy and integrate, and which parts should you build.
Healthcare and mobile health products like the ones we build rely on the right framework to deliver healthcare outcomes supported by ongoing maintenance. For PPD Act, we leveraged ResearchKit to accelerate development time and minimize costs. The package of consent forms, surveys, and other necessary documents allowed us to focus on the patient experience, rather than reinventing the digital process for collecting informed consent and patient data. In another case, Contentful CMS proved to be a perfect fit for HCM Care’s need for a content management and delivery platform for their product serving patients with hypertrophic cardiomyopathy (HCM). Content management is always a good candidate for off-the-shelf solutions, as we’ve written about before.
Start with the Building Blocks, Go Shopping
Component-level, decoupled elements should generally be on your shopping list, rather than in your developer’s backlog, whether that talent is in-house or with a partner like us. Prevailing wisdom in product strategy cautions against innovating unless there’s a clear reason for reimagining the way things are done.
Development practices are producing more and better microservices, especially ones that handle transactions, database management and infrastructure, which is great news for product companies in healthcare. Though many of these microservices aren’t health-specific, they integrate into a stack that supports the regulatory and data security needs of the industry.
We generally recommend that products be built using existing solutions for:
- Email & Email Marketing
- User-backend systems
- Content management
- Analytics Engines
Buying these elements can both save money and reduce risk, though we recommend vetting any 3rd party component from several angles . A thorough look should calculate switching costs, assess vendor viability and information security risks, and determine fit with stack and lifecycle of your product. By the way, we do that before we make recommendations about any vendors.
One further thought about buying components: be aware of how you’re making decisions. You want to make dispassionate choices, rather than allowing superficial signals or an urge to control every detail of the final product hurt your immediate and long term prospects. I know it can be very appealing to develop proprietary everything until you see how challenging and expensive it is to completely scratch-build a health data model, for example. The devil’s in the details, and these particular devils are better avoided than engaged especially with a solution as available as HL7 FHIR.
When Custom is the Best Bet
When Orpyx SurroSense needed a wireless communication profile and an intuitive UI that worked for their proprietary pressure-sensing insoles, our team knew we needed to build something specifically for them. The SurroSense app still included existing graphing and reporting libraries to efficiently and beautifully communicate data in the app we custom-built.
For Orpyx, we saw an opportunity to balance control over the data, speed to completion, and function with cost by purchasing some libraries and build others ourselves. The result is a product that continues to improve function for people with lower extremity neuropathy.
Polish and substance are the table stakes for entering the healthcare market. Ultimately, the parts of your product, regardless of their origin, have to function seamlessly and feel cohesive from the user’s perspective. User-centric development orients our work toward this overall goal. Custom development is often the best way to integrate a mix of proprietary and vendor-built components on the backend and present a UI that reflects state-of-the-discipline behavioral change research. When it comes to behavior change, how everything ties together is often the crux of the challenge, which doesn’t rule out existing technology, but the key innovation is the unique user flow. Focusing time and dollars at this part of the product just makes sense.
You and your development partner should think about exactly where to apply specific expert skills because a misstep here is costly. Failure to focus the scope of custom development risks delay, expense, and duplicated efforts, none of which may actually change outcomes for patients, researchers, providers, or anyone else you might seek to serve.
Ask few key questions before making a decision to buy or build essential elements of your solution.
- Is there existing technology that covers your use-case?
- If yes, how closely, and could some tweaking make it workable?
- Could the problem even be solved, if there isn’t an existing option?
- How critical is speed to market?
- What’s the initial price, and how much will you spend in maintenance costs?
- What would replacing the solution look like?
- Are IP and data important right now, and will they be in the future?
Answer those questions with your business goals in mind, and the answers start to reveal where to build and what to buy. The fundamental process of excellent product strategy is this depth of inquiry, and ensuring that these questions inform your development decisions.
Want more insight into the critical steps in healthcare product development? This is the first post in a series where we’re exploring the different facets of developing digital healthcare technology, from apps to IoT, in a series of posts. There’s plenty to cover in best practices for research apps, measuring behavioral change, agile development, and the value of long-term technical partnerships.
If you’re interested in hearing what this mix might look like for a product you’re building, email us, and we’ll give you our assessment.