Every software company has to make build-or-buy decisions for every part of their stack. Unless it is your core business, you don't build a globally-distributed network of data centres: you use a Cloud provider like AWS, GCP or Azure. You don't build authentication systems from scratch: you use a dedicated service like Auth0, AWS Cognito, Azure AD etc. You don't build payment infrastructure: you use Stripe. There are many more examples of these decisions in the comments on this LinkedIn post, but what factors should you consider when faced with such a decision?

From our experience there are four key questions that need to be answered should you go down the build route:

• Knowledge - who else knows how this component works?
  • Carefully considering your "bus factor" in the literal sense of what would happen if the person who implemented the system gets hit by a bus - would your decision ensure there is business continuity?
  • Do you have the domain expertise in-house to develop and support this? For example, if you are embarking on developing your own prediction model without any Data Scientists then things aren't likely to go well.
  • Technology trends and best practices are extremely fast moving (especially in the JS ecosystem), how are you going to ensure the chosen solution keeps moving forward and evolves with the industry?
• Maintenance - who will keep this component up to date and manage its scaling and availability ?
  • If you decide to buy this should be handled for you either for free or via some support package.
  • Building in-house now requires an organization decision for how these components are owned and managed. Options include dedicating a team to maintain core services, establishing a guild model like Spotify or just hoping that someone is willing to own it (you still have to deal with the bus factor in this scenario).
• Evolution - as your business requirements change how can you evolve this system?
  • As we outlined in our recent article - The never-ending product requirements of user authorization - business requirements are always changing rapidly due to factors like customer growth, market shifts and regulatory requirements.
  • If the solution you pick is not flexible enough to be adapted and scaled to fit your evolving business, you will spend valuable time and resources on trying to make the solution work or replacing it with something else.
• Scaling - has this component been designed with scale in mind as you grow the business?
  • If your business grows 10x or 100x, can the solution handle that extra demand smoothly.
  • Thinking ahead to how the system may need to scale as your architecture grows and evolves - going from monolithic to microservices is usually a tipping point where a solution needs to adapt to support a distributed model.
  • A good example of this is a recent talk from Netflix that discusses their issues scaling RBAC and how they moved to ABAC.

Maintenance and evolution are the most underestimated factors that can end up bogging down your entire operation. For example, if you don't actively keep track of security vulnerabilities or new regulations and update your systems to handle those, a breach can bring your entire business down or cause significant damages in the form of reputation loss and legal issues.

The InfoSec Institute recently wrote about The Dangers "Rolling Your Own" Encryption highlighting examples where companies have decided to undertake the task of writing their own cryptography rather than using a standard and suffered the consequences - most famously Telegram whose MTProto used to provide end-to-end encryption proved to be crackable. With messaging as the core business the decision to keep building their own crypto has required a big investment in both time and money, but they have also suffered the reputation hit.

Sometimes, building a solution in-house is the right decision to make:

• Integration - The solution is designed exactly to meet your requirements at the time of development -- which might be simpler and faster to implement than configuring one or more generic off-the-shelf tools to achieve the same thing.You can integrate the solution more tightly into your stack and make use of familiar tools and processes to manage it.
• Compliance - Some industries have strict regulatory requirements that may require owning the full software supply chain with auditability and oversight. Conversely, some regulations might actually require using industry standard or certified components for certain parts of your stack.
• Ownership - For business-critical components, not relying on external vendors can be a form of risk reduction.

The decision to build or buy is not a light decision to make. There are many factors that influence it. In general, building in-house requires significant ongoing investment on people, training, infrastructure and security. Implementing an off-the-shelf product also requires some investment for training, support and infrastructure. But, if you get industry standard or open source components, the investment required over time is significantly less because you can tap into the collective expertise of a wide community of experts who are willing to provide support, build new features, fix security issues and keep up with the evolving industry trends.