When To Build Engineering Tools And When To Buy Them
Hacking the Engineering Process is a San Francisco-based meetup, which opens discussion for software engineers and tech enthusiasts to share their thoughts on leading topics, pose thought-provoking questions for each other, and learn more about how various engineering teams measure developer productivity amongst themselves.
In March, the guest speaker was the VP of Engineering at Apartment List, Sue Nallapeta. Nallapeta is a leader in tech and is passionate about building highly performant and vastly scalable engineering systems. One of the questions that many engineering leaders often contemplate is whether or when to build or buy software in the process of building a product. Companies invest a lot of time and resources into building software, while buying software can also be expensive in other ways. In her talk, Nallapeta described the “7 C’s” she considers when making this decision between build vs buy and shared her experience in implementing this process while developing Apartment List.
The first C is Capability, which is determined by the problem that you are solving for, including any features you need or want to build. This is a product and a business’s core, and often what makes it stand out amongst others. These capabilities are what you want to go to market with and what your customers will use. The question then becomes whether these capabilities already exist. If so, developers need to decide whether it is worth building them from scratch or using the tools that are already available, which is a decision that depends on how quickly the product needs to go to market and which path would help achieve the goal most effectively and efficiently.
There are two common dimensions to cost that most people will look at when building. The first is resources, including how many engineers a team may need to develop the product. The second being time, on how long it will take for those engineers to build the product given the resources they have available. Most teams will consider the two and choose the cheaper option. There are, however, other pertinent costs that can and possibly should impact your decision: build time, maintenance costs (to monitor the product, support it, build test cases, etc.), infrastructure costs, and hosting costs (which are hidden but can add up to a lot).
There are other costs if you choose to buy. Transferring a solution you already have or integrating a new tool can be time consuming and have major migration costs. Buying software also involves onboarding costs (how long it takes for engineers to learn the new system and become comfortable with it) with offboarding costs (typically there is an overlap between old and new systems) and maintenance costs for successful long-term integration. It is crucial for teams to think beyond these two dimensions before making a decision based on cost.
In order to build systems that are easy to understand and explain to others including the sales team, growth team, and all business stakeholders. Teams often build products that are very complex, and complexity also grows as the product scales. For example, Netflix’s scale was so large that they needed to invest in their own Content Distribution Network (CDN) and built Open Connect, which they can ship to all ISPs to cache videos on the client side to deliver content quickly.
A product’s build speed heavily depends on the team’s competence. Do we have the right engineers on the team who understand what needs to be built? Do they have the experience and domain knowledge to understand what we are solving from the business and customer perspective? Do they work well together? If not, how long will it take to hire and build this team? Building a competent team can take upwards of 3–6 months just to hire. At a previous company, Nallapeta’s team acquired over 10 companies, each acquisition immediately adding value in the span of a couple of months. If they built, it would have taken several months or more to add those capabilities.
Cohesion, or connectedness, is tricky in the case of buying — whether the feature you are buying integrates with the other systems that you already have. For example, Apartment List uses Salesforce for Customer Relationship Management (CRM), and any other software they build that ingests data should support sending data to Salesforce. You can create value through an ecosystem of softwares, where systems coexist with each other and are dependent on each other.
Any product needs to be able to compete once it enters the market. Competitive advantage is a key factor decided by whether the product or its features are core to its functionality and to the business. The product’s capability determines if it can be competitive and can ship features faster to win the industry.
Continuity goes hand-in-hand with maintenance. It determines how you ensure scalability of the product as your user base grows and as new feature requests rise. This is important to track so you can guarantee that your system is sustainable and you don’t need to replace the system every few years, which can be a major setback.
Apartment List’s Experience
Build: A/B testing
In building a product that satisfied all of the capability needs, Out of the Box (OOTB) solutions were insufficient for the business need at the time. Apartment List is a subscription based business. The team had to quickly ship many experiments, and try various subscription based models and paywalls, each with changes in prices and features, which would not have been possible without fast iteration.
They also wanted to maintain control over customization to build a great user experience. The product was highly customized for various customers and customers sub-groups. It also provided a great competitive advantage with insights and quicker feature launches with a lower experimentation and test setup, leading to an increase in customers globally.
Build: Billing System
In a high risk industry, the chargeback rates are extremely high. With a subscription based business model, Apartment List needed to maintain fall back use cases such that if a payment does not go through for a customer, the system automatically redirects to a different payment processor, a feature unavailable in other billing system tools. This allowed them to also lower the renewal rates and offer more discounts to their customers. Most importantly, Apartment List’s margin was low, meaning using a tool like Stripe would lead to them cutting into their margins.
Buy: Email Software
Apartment List had initially built their own email software, which was relevant for the stage of the business. At the startup stage, it made more sense to build the software and have access to customized complex features. However, engineering teams did not have the bandwidth or documentation to support the system and over time, as the team who built the software left the company, there was not enough in-house knowledge about the software to maintain it. Eventually using the in-house software also meant that something as simple as a brand update with new logos and colors would require weeks or months of engineering effort.
Apartment List chose Courier to support transactional emails and another provider for marketing emails. This also helped the company achieve cohesion, with the new systems integrating well with the existing system and each other.
Buy: Testing Software
Every company requires some form of Quality Assurance (QA), which, as the product scales, can become an expensive and tedious process that forces engineers to divide their attention away from the product. Using an external tool offers better control and ease of use of the testing software and increases the efficiency of the testing process.
Build & Buy: Analytics
Data is the backbone of any company, requiring high data accuracy and coverage. Every decision made needs to be built on a strong foundation. With evolving business needs, ApartmentList chose to both buy analytics software and build on top of it to close the gaps.
Originally published at https://www.courier.com.