Defining a process for objectively selecting homegrown or purchased solutions
For almost every functional or architectural application component, there are a plethora of ‘as a service’ offerings. We see infrastructure as a service (IaaS), backend as a service (BaaS), SaaS, PaaS.. and a new ‘aaS’ seems to be added daily.
What do all these services have in common? Well, they aspirationally promise to give you, the engineer, (1) more freedom to focus on your core product, (2) faster time to market, and (3) production-ready solutions for complex and repeatable engineering operations.
Sometimes this is case. Sometimes it isn’t. This purpose of this guide is to provide a rational set of objective criteria to assess whether you should build or buy a particular service.
What is build? What is buy?
Build does not necessarily mean that you are making something from scratch. It means that you are combining custom code, open source libraries, and individual/community expertise to construct a solution for your use case. This solution is something that you will design, build, run, maintain, and scale internally.
On the other hand, buy does not necessarily mean that you are purchasing an end-to-end, out-of-the-box solution for your use case. It more accurately represents the purchase of a defined service that adds near-immediate value to your use case. Typically, the viability of the service itself will be guaranteed by the seller and you will not need to design and build the service itself. However, depending on the type of service purchased, you may choose to run and scale it internally. Generally, you will offload the running, maintenance, and scalability to the seller.
The Developer Mind
Before we continue, let’s reset our frame of mind.
Many developers have strong egos, and that’s generally an empowering attribute. Strong egos give devs the confidence to power through complex obstacles, focus for days and weeks at a time, and cultivate entirely new industries. However, there’s a fine line between reasonable and unreasonable confidence.
“I can build ____ in ____ days!”“Ha! I can build a better ____ in a weekend!”“This is so expensive. I’m just going to build it.”
We frequently see and hear these comments on dev forums, aggregators like Reddit and HackerNews, and in our day-to-day interactions. If we don’t say it, then some of us probably think it from time to time. Hey, sometimes we’re probably right, but often times, our initial ego-driven reaction distances us from the objective criteria we apply to our general practice of programming.
When assessing what to build vs buy, or which ratio we choose, it is critical that we reset our frame of mind and approach our solutioning as open-minded and objectively as possible. Excluding the purists, no one cares if we were able to build our product from scratch or if we cleverly integrated a series of purchased solutions together. What people care about is if our product works and delivers exceptional value to customers.
With the build vs buy decision-making process, we will answer the question: “How do we deliver exceptional value to our customers quickly, efficiently, and prudently?”
Build vs Buy Decision-Making Model
Step 1 — Identify and categorize your product’s functional scope
Your team has been tasked with building an ecommerce platform that allows users to upvote and downvote products. So, what are your product’s functional and architectural features?
Functional
- Marketplace service
- Voting service
- Product display service
- Inventory management service
- Transaction service
- Buyer, seller, and admin account management service
- Search, filter, refine service
Architectural and Process
- Databases
- Servers
- Load Balancers
- Dev Environment / Version Control
- Continuous Integration / Delivery Pipeline
- REST / Realtime APIs
- Frontend Framework
- Deployment Controls / AB Testing
While these are not comprehensive feature sets, the important point is that there is a clear distinction between core product features (marketplace, voting), and necessary system & process architecture (server environment, CI/CD pipeline). There are features that are proprietary and unique to your product, and there are architectural features that are found in almost every modern application system.
Your job is to identify which of these features are proprietary to your platform and which are replicable proven solutions. To do this, ask the following questions:
- What are the proprietary, core features that make my application unique?
- What architectural services do I need for my platform scaffolding?
- What is my ideal development pipeline going to look like?
Keep in mind, we are not solutioning yet or deciding what to build vs buy. We are identifying and categorizing our product’s functionality.
Step 2 — Define the scope of work and reconcile against constraints
Based on your feature categorization in step 1, it is time to define the scope of work to build each feature.
First, itemize and prioritize the detailed functionality for each feature:
- What is the minimum functional scope for the feature to be viable?
- What is the ideal functional scope for the feature?
- Is this a feature I need now? Or can it wait?
Second, for each feature, answer the following build questions for the minimum and ideal functional scope:
- How many developer resources do I have available to build this feature? Maintain this feature?
- Can I harness any domain experts to help design this feature?
- Has anyone on my team built this before?
- How much time to design (A), build (B), test ©, deploy (D), maintain (E) this feature?
- Will building this divert resources from something else?
- Do I need to hire additional resources? If so, what is the cost breakdown?
- What is the infrastructure cost to run this internally?
Third, for each core feature, answer the following buy questions for the minimum and ideal functional scope:
- What is my monthly budget for this service?
- How do I anticipate my budget changing over time?
- Can I harness any domain experts to help me assess the best solution?
- What developer resources do I have available to integrate and configure the solution?
- If applicable, will I have the resources to self-host, run, maintain, and scale the service?
Step 3 — Solution divergence
Now we can get to the good stuff! In this step, we are not deciding what to build or buy; rather, we are aggregating an inventory of choices.
First, scour the interwebs, get referrals, and assess the solution ecosystem. Have other teams built this successfully? Have they bought it successfully? What are the horror and success stories?
Second, create a build vs buy comparison matrix. Make sure to note the monthly, infrastructure, and long-term maintenance costs. Note the total upfront and ongoing time needed for each build or buy solution (having build/buy hybrids are great too!).
Step 4 — Solution convergence
Start narrowing down your options.
Remember that buying does not mean out-of-the-box instant magic. There are always build costs associated with buying:
- Sandboxing and initial technical vetting
- Integration and setup
- Configuration and fine tuning
- Operational training and staff onboarding
Similarly, building does not necessarily mean that everything is made from scratch, but it does mean that you will assume the costs of ongoing maintenance, scaling, and debugging. You will also need to train staff and develop new operational processes.
Step 5 — Build or buy or both
Choose a primary and secondary solution option for each feature. This way, you will have a backup plan if the primary solution does not pan out. It is absolutely critical that you involve your team during the selection process and make the selection criteria transparent.
Step 6 — Develop guidelines for reassessment
The solution that you’ve selected for day 1 of your product will likely not fit your product at day 600. This is okay, but we must be able to anticipate and preempt any future scaling issues. To do this, set both quantitative and qualitative benchmarks for triggering a build vs buy scaling reassessment. For example, we’re confident that our current architectural solution allows us to handle up to 500k concurrent connections with ease, but our current growth model forecasts 2m connections in 8 months. When we start to near the 300k mark, then this will trigger another build vs buy assessment so we can preempt any issues at scale. This reassessment should include:
- What have we learned about the needs of our product in the past X months?
- What has been more difficult than anticipated? What has been easier?
- How has our resource and knowledge pool shifted?
- Have our product’s core competencies shifted?
- Is there anything new and better out there?
Final Thoughts — Try It Your Way
Well, this looks like a lot of work. It may even take a day or multiple days to assess a feature. But realistically, when we take into account the full lifecycle of your product, a few upfront days can save you months and lots of money down the road. Those few days may also make or break your product.
Customize your build vs buy assessment process to meet your organization’s needs. Though a large enterprise is way different than a startup, the assessment metrics remain very similar. Add or remove metrics, codify a more refined process, or make your own from scratch.
Either way, it is important to remember that building a successful product is very hard, so don’t make it harder on yourself than necessary. Let your decision be driven by choosing the right solution for your product, rather than the right solution for you.
— —
Original article on RealtimeAPI.io
Want to keep in touch? Add me on LinkedIn