Developers enjoy building everything from scratch but often times the allure of doing so isn’t worth the cost it will incur. Most needs in the development space generally have at least one well known implementation that can be leveraged to get a large portion of the work done without writing a single line of code. In these cases, it makes more sense to re-use an existing library, service or framework rather than building it internally.

Why Not Build it Yourself?

In all development projects, we evaluate how to implement a given component by looking at what’s available on the market and determine what it can and can’t do. Too often we reject a component because it doesn’t work exactly how we want or it won’t respond to our needs further down the road.

The 80/20 rule applies very well here: if an existing component does 80% of what you’re looking for, you should not build it internally. Sure, you might be limited by your choice at some point down the road but who knows if the product will still be around by then?

You should still build an abstraction layer on top of whatever component you’re using. This protects you from technology changes by making it easy to swap out the component without affecting your public contracts. Let’s say you’re building an email marketing engine for your users. You would leverage the power of the product you chose to purchase, but create a layer on top of it that de-couples you from the supplier.

Building on an existing solution enables faster delivery by virtue of not having to re-invent the wheel, but instead customizing it to your own needs. It’s not just development time that you’re saving either; the QA team will find less issues since you’re building off a proven platform and DevOps will have less custom deployment and operationalization work to perform. Everyone can focus on building the pieces of the system that bring business value to customers instead of things that have been solved a million times over.

Building on an existing solution also greatly lowers the risk to your project so long as you keep the off-the-shelf solution up-to-date. Products such as Amazon Cognito (cloud-based authentication) work hard to stay ahead of hackers looking for exploits. It only makes sense to rely on them to ensure that your users’ passwords are kept safe.

Top 3 Components You Shouldn’t Build Yourself

Authentication Platform. If for no other reason than security, go with an off-the-shelf solution. A security exploit in authentication could spell disaster for the entire application. There are great alternatives to building your own authentication service, such as Amazon Cognito or Azure Active Directory (which can stand alone without a traditional AD).

Search Engine. The domain of search is highly specialized and trying to build one from scratch is a recipe for long development time and poor search results. Elasticsearch is extremely popular and customizable to any use case but don’t discount Amazon CloudSearch or Azure Search which can also provide great value.

Deployment Pipeline. Deployment has come a long way since the days of InstallShield. Most cloud resources can be deployed through a multitude of  ways — whether it be Infrastructure as Code or a tool developed specifically for that purpose, like Octopus Deploy. All of these systems are built with hooks that allow you to add custom steps for anything that isn’t directly supported.

This list just scratches the surface. There are many other components that you shouldn’t build yourself since they will cost you greatly for very little gain. Do some research into what products are out there before you start any new development and don’t re-invent the wheel.