Once you're confident that you have a strong understanding of your company's needs, you can begin to evaluate whether you should build or buy a solution. This decision is critical, as it will have a significant impact on your product's roadmap, your engineering resources, and your ability to deliver the best product possible, as quickly as possible, to your customers.
Estimating the Cost of Building
I like to break down the cost of building into the following equation (yes, very scientific):
Total Cost = Cost to build + Cost to maintain + Cost to support + Opportunity cost
Cost to build
The cost to build out a set of integrations can be broken down into a few key components:
- How many separate systems do you need to integrate with?
- How much functionality will your integrations require?
- What internal tooling will need to be built to support your team and your customers?
The part that will likely take your team the most time is understanding how the user experience and data model of each individual system maps onto your own. This is a non-trivial task involving dozens of individual product decisions, and it's one that you'll need to repeat for each system you integrate with.
Cost to maintain
The cost to maintain your integrations is often overlooked. Once you've built out your integrations, you'll need to maintain them. This means keeping up with changes to the APIs of the systems you're integrating with, as well as changes to your own product that may impact your integrations.
Schools adopt new systems and processes that may affect your integrations and when you want to support new functionality through your integrations, you'll need to update each integration to support that functionality.
Also, consider the composition of your engineering team. Integrations are often built and maintained by a small number of engineers on a larger team. If these engineers leave the company, you'll need to find new engineers who can understand and maintain the integrations they built. This is a common issue with in-house integrations, and it can be a significant long-term cost to your business.
Cost to support
The cost to support your integrations is another often-overlooked aspect of building in-house. When you build your own integrations, you're on the hook for supporting them. This means that when a customer has an issue with an integration, your team will need to troubleshoot and resolve that issue. This often requires highly specialized knowledge about a large number of individual systems, and it can be a significant drain on your team's time and resources.
As your company scales, it is inevitable that you will have to build out additional tooling for testing, monitoring, and debugging your integrations. This will likely include a dashboard for your non-engineering team members to onboarding new customers, browse through data, and troubleshoot issues.
Opportunity cost
Opportunity costs are discussed at length below. My one comment unique to this section is that there is a hidden cost involving your competitors: If your competition outsources integrations and you do not, you risk the market surpassing you. Not only do you have to keep up with competitors on product features, but you also have to keep up with them on integrations - which means keeping up with an external company (like Edlink) that is dedicated to doing just that.
Estimating the Cost of Buying
Estimating the cost of buying can be done using a similar equation to the one above:
Total Cost = Upfront cost + Cost of implementation + Cost to support + Opportunity cost
Upfront cost
This one is pretty easily calculable. It's the amount of money that you have to spend upfront to buy a solution. This is often a fixed cost, and it's usually pretty easy to understand. In the case of Edlink, there is no upfront cost.
Cost of implementation
The cost of implementation is the cost of getting the external solution up and running. This can include things like training your team, setting up the solution, and integrating it with your existing systems. In the case of Edlink, this can be estimated by taking a fraction (e.g. 1/2) of the time you believe it will take to build one integration. The reason we use a fraction is that it is generally easier to integrate with Edlink than to build a connection directly to (even a single) a source system. This is because:
- We have already made a lot of the product decisions for you based on our experience with other customers.
- We can provide guidance on a number of architectural decisions that you would otherwise have to make yourself.
- Our APIs are specifically designed to be easy to use and integrate with.
- We can provide sandbox environments for you to build and test your integrations in.
Cost to support
There are two things to consider here:
- How much time will your team spend supporting the external integration solution?
- How much does the external solution cost on an ongoing basis (i.e. in cash)?
The second point is relatively easy to calculate; the first point is a bit more difficult. However, it is generally safe to assume that the cost of supporting an external solution is lower than the cost of supporting an in-house solution. This is because an external solution provider like Edlink has a team of engineers dedicated to supporting the solution, and they have a vested interest in making sure that it works well for you.
Opportunity cost
Opportunity costs are discussed at length below, but they are minimal in this case. The only "opportunity" to compare against is the opportunity cost of building no integrations at all. This is (honestly) a very worthwhile question to consider during the evaluation process and it is something that we discuss further in Understanding Your Needs. Even spending a few weeks building out a relatively simple integration with Edlink is time that could be spent elsewhere.
Properly Valuing Opportunity Costs
Properly valuing opportunity costs is a critical part of the decision making process. All too often, people focus on the tangible costs of a decision and ignore the opportunity costs. This is understandable, as opportunity costs are often difficult to quantify and even harder to explain to your team. However, failing to properly value opportunity costs can lead to poor decision making and missed opportunities.
What are Opportunity Costs?
First, what even is an opportunity cost? Opportunity cost is the value of the next best alternative that you give up when you make a decision. For example, if you decide to spend engineering resources building an integration, the opportunity cost is the value of the features you could have built instead (given the same resources).
Understanding Opportunity Costs
When you choose to buy a solution off-the-shelf (e.g. Edlink), you are spending a quantifiable amount of money. If you choose to build something in-house, the most value that your in-house solution can provide is the total cost of the off-the-shelf solution.
For example, if you spend $50k per year on payment processing fees and you decide that you want to build your own payment processing system, the most value that your in-house solution can provide is $50k per year. Even if you believe that you can build such a system for less than $50k, you're almost certainly better off spending those resources on other projects or features to drive new sales of your product. The total value of new business acquired by improving your product is theoretically uncapped, and at the very least, likely to be much higher than the $50k you would save by building your own payment processing system.
When It Makes Sense to Build
The one situation in which it makes sense to build in-house is when the feature you're thinking of building or buying is a truly unique differentiator for your product. The reality of integrations is that they are rarely differentiators. They are often a cost of doing business, and building them in-house is almost always a poor use of resources.
- If you're looking to build a deep integration with a particular system (e.g. in order to form a cottage-industry around that one system), then building in-house might make sense.
- Another situation in which you may choose to build in-house is when you have an excess of engineering resources and a shortage of other valuable projects to work on.