#10 - The 7Cs Framework for the Build vs Buy dilemma | Sue Nallapeta, CTO at Trusted Health
I travel the world and the 7 Cs, everybody's looking for... software ♪
Hey friends! Here we are… our 10th in-depth article about Engineering Leadership, written in partnership with another world-class leader! This week, we’re inviting Sushma (Sue) Nallapeta, CTO of Trusted Health and a long-time Plato community member. She’ll talk about the Build vs. Buy dilemma right below!
If you’re not subscribed yet, the button below allows you BOTH to win your ticket for Elevate’24 (worth $1,200) and to never miss another article! Winners announced on March 21st.
Let’s go!
Sue Nallapeta, from Director to CTO, along with Plato
Sushma (Sue) Nallapeta started her career in tech 15 years ago and spent a decade in tech leadership and executive roles. She’s currently the CTO at Trusted Health. Before that, she was a VP/Head of Engineering at Apartment List and Zoosk right before. She’s thus navigated various growth stages throughout her career, building, acquiring, and enhancing diverse software solutions. In her role at Trusted Health, she leads a team of 100 engineers, working towards connecting healthcare professionals with valuable job opportunities.
But beyond her impressive background, Sue has been pivotal to our growth at Plato! She’s a customer, an investor, and a cherished advisor. She’s always been there to support us, in good and bad times, guiding and cheering us up during challenging periods, and listening to our (sometimes) crazy ideas. She’s also a Plato mentor, giving back to the community; and a mentee, because like for each of us, learning never stops! She’s also spoken at several Elevate conferences, and this article is based on one of her keynotes. We’ve seen her grow too, from being a senior director of engineering at Zoosk, to a CTO at Trusted Health, and as a VP of Engineering in between!
You can learn more about Sue Nallapeta on LinkedIn.
The 7Cs Framework to Decide Between Build and Buy
Build vs. Buy is like the tech version of Shakespeare’s “to be or not to be”. Though not as dramatic as what happens in Hamlet, teams often get stuck in this conundrum of buying a capability outright or building it from scratch.
This is a dilemma I’ve faced many times in my career, and I'm here to explain the 7Cs Framework, to help you make a decision the next time you stumble on such a challenge.
Build vs Buy: the “to be or not to be” of Tech
This is the eternal debate among tech teams: what’s right between building and buying software? And it doesn’t help when you see that both practices are followed simultaneously. Here are a few examples:
Instacart leveraging Stripe's capability for speedy grocery delivery
Netflix developing its own Content Delivery Network (CDN), ditching the existing CDN service
Lyft using Twilio Flex to manage relationships with their customers
ServiceTitan leveraging Zapier instead of building an integration service from scratch
As a tech executive, I’ve navigated many contrasted scenarios. One involved building a billion-dollar business using software acquired for $2,000 on someone’s credit card — an e-commerce platform that powered gift cards, which served us well for more than five years.
On the flip side, I've been part of a company that spent over $100 million on photography tech and patents, only for them to end up in a fire sale. These experiences are perfect snapshots of the unpredictable nature of making build vs. buy decisions.
But then, why do we feel we are always making the wrong decision?
In my own professional journey, I’ve been in situations where – with hindsight – past decisions appeared misguided. For instance, we underwent the (daunting) task of switching data warehouses twice in a year: first, from RedShift to Snowflake and then, from Snowflake to BigQuery, due to intricate operational challenges. Living through such experiences underscores the complexities of decision-making.
Two aspects make it even more complicated::
Ego – many times, decisions have been made by other folks at another time and it is difficult to challenge the decision or admit we should change now. They had strong reasons to make the decision then, and challenging that decision can be perceived as an attack on their skills and knowledge. This is pure human psychology.
Timeline – Most past decisions were made at other times, when the company was at a different stage, with different funding levels, a different macro-economic environment, and sometimes, even a different product.When you look at these decisions with the context in mind, it becomes very clear why they were made in the first place. But times change.
I've made (and lived through!) those bad decisions myself. Sometimes, we tend to beat ourselves up too much and be too involved emotionally. I now try to have a more rational approach to those decisions, using the 7Cs framework I’ll share below.
The 7Cs Framework
I’ve put together a framework, based on my past experience and how I evaluate Build vs. Buy decisions, and it has helped me greatly since. I call it The 7Cs Framework. I'll share many examples from my experience below, and walk you through each scenario where I had to make those decisions.
1st C – Core Capability
The first of the seven Cs in the framework is Core Capability.
Even if you buy initially, you might eventually end up building it.
It covers your core set of features. So, if you're a product company, your core capability is the product itself. This is what you want to get right at all costs. When building a core capability, you must often make an important decision. Do you want to build this capability in-house or procure it from outside?
But even if you buy initially, you might eventually end up building it. because this is what your value proposition and product are about. And you’ll want to customize that core capability for your customers and business needs.
For instance, in the case of Apartment List, the rental marketplace I worked for, our core capability was the product where renters find homes. At Trusted Health, our core capability is the platform where nurses find jobs.
So, your first job is to define what your core capability is, and decide whether you are okay (for a time!) with the idea of buying it before ineluctably building it.
2nd C – Cost
Think about cost as a whole ecosystem instead of just fragments of people and time
Next comes Cost, the second of the 7 Cs.
People often think about cost in two dimensions: time and people. How long will it take me to build? How many resources do I need to build it?
But in my opinion, this reasoning is incomplete. You need to think about many more things when determining the cost. Think about the maintenance cost. It's often the big one. You need to continue updating the libraries that might be approaching their end of life, you need to maintain test cases, you need to maintain your build-and-deploy scripts, etc. The other prominent drivers are the costs of hosting your infrastructure and licensing costs. All of these factors come into play.
So, think about cost as a whole ecosystem instead of just fragments of people and time. Doing so will help you accurately determine the cost viability of a project, thereby simplifying your build vs buy decision.
3rd C – Complexity
The third in the list is Complexity.
There are two types of businesses: either they’re extremely complex, or they are really simple. This complexity determines whether you want to build or you want to buy. In the case of Netflix I mentioned above, where they built their own CDN, the team was trying to solve a specific issue: providing their customers with the fastest streaming service. To achieve this, they shipped devices to ISPs and then cached those videos on the client side to deliver them faster. Building this complex infrastructure was worth it for them.
Similarly, at one of my previous companies, our operations were extremely complex. Off-the-shelf options didn't meet our needs, and we thus decided to build our billing and payroll systems.
Depending on the complexity of your operations, you’ll have to determine if existing solutions fit your needs, or if you have to build the feature from scratch.
4th C – Competence
The fourth of the seven Cs is Competence.
This pertains to the resources you have to support the project. Do you have the right people within your company to build it?
When answering the question, remember it's neither about tech skillset nor about learning or upskilling. It's about the business side: the opportunity cost and time to market, i.e. how fast you can get your software in front of the customers.
When you don't have a product-market fit, there's no point investing a lot in one particular technology or another. You have to have an open mind. I've faced situations where we moved from Series A to Series B and lost our product-market fit. For competence, instead of building internal competency, you can partner with vendors who possess that. Make sure you evaluate your skillset (both technical and business) to make the decision.
5th C – Cohesion
The fifth C on the list is Cohesion.
This has to do with the integration needs of your existing system. As a tech business, you have an ecosystem of systems, such as a CRM suite, marketing tech, or analytics solutions. How can the software you're building or buying fit into that ecosystem? For example, we use Salesforce as our core CRM, and we cannot possibly have a system that doesn't integrate with Salesforce.
To make the build-vs-buy decision, make sure you take those integrations and tool compatibility between all of your systems into account.
6th C – Competitive Advantage
The penultimate C is Competitive Advantage.
It requires asking yourself when developing a specific piece of software, can it provide you with a huge competitive advantage?
In some cases, buying it is the right option. For instance, there are a lot of companies that use Large Language Models (LLMs), like GPT-4, to create unique solutions. You don't have to build your own LLMs, unless you're solving a very complex need with a dataset that's not readily available. Buying or licensing it makes much more sense business-wise.
On the other hand, when building our online dating service at Zoosk, we were operating in 35 different countries across different currencies and languages. It was a huge competitive advantage for us to build our own internal systems across different dimensions, like A/B testing or billing systems.
The question is thus, whether building or buying can bring you a competitive advantage; and it’ll all depend on the situation and business goals. If it doesn’t, then you’re usually better off buying.
7th C – Culture
The last C stands for Culture.
This is an underrated factor that can still play an important role. Oftentimes, people have a specific mindset that pushes them towards building software. They want to continue attracting talent, focusing on innovation, or investing in their people. In other situations, the culture can be different – especially if you aim at entering a market faster, and you’ll skew towards buying software.
Depending on the company culture and general mindset, you may have a better opportunity cost choosing to buy or to build, but your hierarchy may not allow either one because it’s not customary in the organization.
Try to understand your company culture, and shift the general mindset (or yours, if you’re the end decision-maker!) to make rational decisions that aren’t influenced by usual practices.
In a nutshell, here are the 7 Cs from my framework:
Core capability
Cost
Complexity
Competence
Cohesion
Competitive advantage
Culture.
Using the Framework to Make a Decision
As you think about building vs buying, seven Cs could be too much to focus on, especially if you evolve in an earlier-stage company. Hence, I would focus my attention on these three factors, which, in my opinion, are the ones with the biggest impact on your final decision (my Tier 1):
Cost
Core capability
Competitive advantage
Everything else can be worked around, but these three are essential. Had I to rank other Cs, my tier 2 would be Cohesion and Complexity, while tier 3 would be Culture and Competence. Start the decision-making process with Tier 1 factors and if not able to make a decision, look into Tier 2 and Tier 3.
Finally, I would say even if you can decide with Tier 1 factors, it’s always valuable to look into the other factors so that you know what you are getting yourself into.
Derisking your decision with POCs
One last recommendation I can provide is to use POCs strategically: you can (and sometimes, you should!) experiment to make better decisions. In cases where the cost of failure, or the cost of adoption are very high, for instance, it is a great practice to test things out first. Let’s say you want to change your customer support software provider: you’ll need to migrate all of your previous tickets to the new system, train people to use the new piece of software, rework the set-up to make sure automated emails use the right wording and branding, rebuild your integrations and analytics, etc. The switching costs are very high in such a case.
“In cases where the cost of failure, or the cost of adoption is very high, for instance, it is a great practice to test things out first.”
One way to derisk the migration to new software will be to test extensively, maybe through a pilot with a subset of the team, before rolling it out to everyone (or ditching it and building your own… or sticking to your previous version). This philosophy applies to any type of software that has high switching costs, such as DevOps tools for instance.
There’s another case where POCs can be useful: when you plan on building a feature with uncertain business results. Let’s say I want to add an AI feature to my product: I’ll then buy ChatGPT to use it as my playground. I’ll check if the prompts I plan to use for my feature yield satisfactory results. It’s faster and will give me an idea of whether to build the feature or not.
Sometimes, you can demonstrate business value quickly through a POC made by purchasing external software. But again, complexity can step in, which makes the “buy” solution inadequate: if your tests with the software you bought show insufficient results, you might have discovered a competitive advantage!
…but enough with theory, let’s now dig into real-world examples!
Build vs. Buy: Real-life Examples
A framework is only good if it can be implemented in real life. I’ve compiled a few examples that can give you an idea of how you can put it to work in practical situations.
Why did we build our own Payroll System at Trusted?
We could have opted for an off-the-shelf payroll system, but we made the strategic decision to build our own. Two key factors from the 7Cs influenced this choice: capabilities and competitive advantage.
Trusted Health, which is dedicated to helping nurses secure jobs, operates in an industry that was notably antiquated nearly five years ago. The prevailing practices among competitors were rooted in traditional methods involving email and phone conversations. Recognizing the opportunity to innovate, Trusted Health emerged as one of the first companies to pioneer a true marketplace and platform for nurses.
The decision to build our payroll system stemmed from the desire to create a unique and unmatched experience. As we onboarded nurses, we realized that offering them W2 employment status rather than the standard 1099 contractor arrangement would be a significant competitive advantage. This approach allowed us to provide comprehensive benefits such as 401k plans, overtime pay, and more. The intricate structure of this vision led us to develop our custom payroll system. Offering a custom, competitive experience to all nurses made Trusted Health stand out, and the “build” route hence was naturally chosen.
Why did we buy Customer Engagement Tools at Trusted?
While the previous example highlighted building our system, we also buy software at Trusted Health. We thus have a huge suite of tools we bought, like Zendesk, Salesforce, Front, Intercom, etc. These tools together help us manage our relationships with customers. The primary driver behind choosing to buy rather than build was the complexity involved. We required real-time communication solutions, and opting for existing tools spared valuable resources that would otherwise be spent on development. Scalability was another critical factor, particularly during our rapid 50x growth amid the COVID era. The readily available options allowed us to support such unprecedented levels of scale efficiently.
The decision to purchase these tools was further influenced by their advanced reporting capabilities, which align seamlessly with our operational needs. Cost considerations also favored buying over building, making it a financially prudent decision. Additionally, maintaining consistency for our customer success team played a crucial role. Opting for established tools avoided extensive training and ensured continuity in our customer support operations.
Why did we buy Email Software at Apartment List?
At Apartment List, we initially built our email system in the early stages. At that time, the operational complexity was low, and the volume of emails was manageable. However, as our email interactions and touchpoints increased, the need for additional functionalities like push notifications and in-app notifications arose. Consequently, we transitioned to purchasing dedicated email software.
In-house development lacked the expertise required for advanced capabilities, and the realization that any internally built system would eventually reach its end-of-life necessitated a shift in strategy. Continual iteration and modernization proved challenging unless the software aligned with our core capabilities.
The decision to buy email software provided significant business control, allowing our marketing team to customize templates and manage all marketing communications. Over time, we acquired two distinct software solutions for transactional emails and marketing. Off-the-shelf email systems offered a more cohesive solution compared to our internally developed system. Deciding to purchase software was a logical response to the growing demands on our email infrastructure.
Why did we acquire a Chatbot (company) at Apartment List?
There’s one specific example I have in mind at Apartment List, where we neither bought nor built the system. Or, maybe we did both at the same time: we acquired a company to ramp up our chatbot functionality.
When leasing agents weren’t available, we needed to nurture our renters and answer the most common questions automatically. Many of our engineers wanted to take on this challenge, but we couldn’t have built anything in less than 12 months. When you use software powered by AI/ML, one big part of the job is to define the data you train it on, and fine-tune it continuously, which would have taken us a lot of time as well – while it was already available on the market.
Now, you may wonder why we didn’t just buy the product and instead decided to acquire the company. The first reason was that the company had the right capabilities for our use case (AI engine, relevant training data, real customers using it, and a bunch of “coherent” integrations with the property management software we were using). But each and every company in the real-estate industry has very unique needs, and buying off-the-shelf software usually ends up creating a so-so experience. We found great synergy in acquiring this company, as they could focus on our needs, accelerate our time to market, and thus give us a big competitive advantage: it took us 3 months, instead of 12, to release the feature.
When we acquired it, the chatbot company was still in its early stages, with 6-7 skilled employees. They had a vision similar to what we were doing at Apartment List, software that was creating synergies and matching company culture. The acquisition opened up a new line of business for us and created a unique selling point (USP).
Acquisitions can be a strategic option for you, if you see a form of cohesion with your current business, a cultural fit with the company you acquire, a boost in your core capabilities and a new competitive advantage. The product became integrated with Apartment List, but we also kept a standalone SaaS for direct customers. Sometimes, the right solution is neither build nor buy, but acquire!
Why did we build our own Billing System at Zoosk?
At Zoosk, we chose to pursue the build route for our billing system.
Certain industries have very strict requirements in terms of how they manage risk, and dating is one of them. We used to experience a lot of chargeback rates as subscription was primarily an emotional decision. Billing systems like Stripe didn't account for such high chargebacks and could have had us banned or penalized – especially as we also experienced a lot of fraudulent activities. Additionally, the margins were pretty low and using external software would have eaten away part of our revenue because of payment fees.
Another reason why we decided to build was the fact that we were present in tens of countries, each with specific legal requirements. Working with cross-national regulators added to the complexity, and our only choice was to make sure our feature was highly customized to our needs and obligations.
Why did we buy AND build Analytics Software at several startups?
I've been to different companies where it's been a combination of building and buying analytics tools. Some end up building, others prefer to buy, and some companies do both. I have seen companies buying insight products like Amplitude, Fullstory, and Product Insights, which capture customer engagement on the website; I’ve also seen teams using tools like Google Tag Manager and Looker Studio to power their BI and optimize revenue operations.
On the flip side, I have seen people building event dictionaries, pipelines, data governance tools, data transformation tools, native reporting tools, etc. At Trusted, we have a SaaS product along with our marketplace product. Our SaaS works directly with hospitals, which requires native reporting capabilities. As it was a core functionality, we decided to build it.
Analytics software is a tricky topic, because it’s usually not a core capability, and yet it has a strong impact on your business objectives. Your decision will depend on many factors, ranging from complexity and cost to cohesion and competitive advantage. In such cases, it’s important to be aligned with other teams, and make sure the decision you make makes sense business-wise.
Wrapping Up
With all these examples, what has become very clear is that there's no one-size-fits-all response to the build-or-buy dilemma. The 7Cs framework should give you clarity and help you make enlightened decisions where affect is put aside, but you’ll be the one making the call in the end!
Here are three factors that will have a significant impact on what you choose to do:
The stage of the company. You need to ensure that at different stages of your business, you are paying attention to product-market fit, economic moat, differentiation, profit margin (Can you afford to build something and continue to maintain it? Can you afford to use an external service that might cost more in the end?), competency, etc.
Thinking about strategic competitive advantage vs opportunity cost. If you're building something that you can package to your customer, it makes sense. But if it's a one-off offering, buying is a preferred option. You should avoid investing your resources in something that is not your core capability.
In true reality, you'll be both building and buying stuff. You'd have to build on top of what you buy to customize the solution for your customers. Be open-minded to using solutions in different ways tailored to your business needs.
Closing thoughts
The ultimate answer to hard questions is most often: “It depends” – and this Shakespearean puzzle is no exception. In most cases, you’ll end up buying existing solutions and building your own at the same time.
But there are situations where you’ll buy, and build on top of what you buy to create a cohesive system. Salesforce is a prime example. It’s one of the most used CRM software, and people put a lot of effort into integrating it with their existing stack.
In some other situations, your decision will be relevant only at a point in time. As I mentioned earlier, at Apartment List, we first built our email capabilities in-house, before switching to buying two platforms for emails and notifications. Both were more performant and gave more flexibility to our marketing teams. Another example I have in mind is at Zoosk, where we built our A/B testing platform from scratch. The reason was that Optimizely was still in its early stages, and feature flagging software like LaunchDarkly weren’t even a thing. We built it all at the time, but if we were launching today, we’d scrap the custom platform and buy it instead.
Decisions aren’t set in stone. Building a custom payroll system at Trusted Health made sense when we decided on it, but better options are coming to the industry and make us rethink. Tech evolves, products are discontinued, and your company changes. As you evolve, so do your needs. Make sure that you reevaluate past decisions based on where you are now; even if it means for you to start from scratch and use the 7Cs framework again.
The 7Cs framework guides us through the maze of building vs. buying software, but it won’t give you definitive answers: only a way for you to make better decisions. Stay flexible, revisit decisions often, and embrace the reality: a mix of both often is the best solution!
That’s a wrap! Huge thanks to Sue for her work on this article :)
And here’s the usual question:
Cheers,
Quang & team at Plato