Building it from scratch doesn’t make you a better hacker – it makes you a slower one

Many programmers seem to romanticize hand-coding software from scratch, believing it makes them a better developer. I must say, this attitude reminds me of the woodworker who refuses to use power tools to make their work easier and faster, instead choosing to saw and chisel and plane everything by hand in pursuit of pure craftsmanship and the satisfaction of perfecting their skill.

That’s not to say that one approach is inherently better than the other; they simply reveal different priorities.

Just like with woodworking, the developer who takes shortcuts by using all the tools at their disposal is likely more focused on the outcome or finished product, whereas the developer who wants to do everything themselves is focused on the creation process or the challenge of solving the problem.

While the latter method certainly has merit and is an excellent means of cultivating your skills as a programmer, the truth is that building your entire product from scratch doesn’t make you a better developer – it makes you a slower one.

For most product teams today, the goal is to get an MVP to market as soon as realistically feasible. Sure, you could lovingly build each and every component of your software from scratch, or you could plug and play existing modules that are not only perfectly viable but often far better than anything your team could build even if they had infinite time to do so.

This is not an indictment of your team’s skill, it’s simply because the teams that built these SDKs and APIs specialize in that building those particular features, whereas your team would probably have to figure a lot of it out as you go.

There’s no shame in using an API or pre-built solution to provide core functionalities. In fact, given the productivity and efficiency gains you can derive from opting for a quicker solution – among other benefits – it’s a much smarter move. When it comes down to it, hacking is all about agility and lean efficiency.

Why spend countless hours coding a feature from scratch when there are perfectly good off-the-shelf options available that can free up your team(s) to focus on solving truly unique problems that set your product apart and perfecting the user experience?

Benefits of integrating pre-built features into your product

As we’ve seen, there are a number of upsides to incorporating ready-made features in your software instead of building everything from scratch.

Let’s take a closer look at some of those benefits:

• Due to the significant reduction in development time that goes hand-in-hand with integrating out-the-box solutions, you’ll benefit from much faster implementation.
• Contrary to popular belief, pre-built solutions are often highly customizable using SDKs, which means that you don’t need to sacrifice uniqueness for the sake of efficiency.
• With robust documentation, plug-and-play solutions are easy to implement.
• Outsourced or pre-built solutions are highly scalable because they’re modular, which means you can scale the infrastructure for a single feature without needing to scale the rest of your product at the same pace.
• This same modularity allows you to quickly deploy fixes and updates without needing to add it to the development queue or schedule site downtime.
• Dedicated developers mean your feature never takes a back seat while other projects get priority.
• Out-the-box software solutions tend to follow industry standards and best practices, as well as comply with industry-specific regulations, which can make it a lot easier to build compliant apps and platforms.
• Perhaps the biggest perk of outsourcing features is that they typically come with product support, lightening the load for your own support team.

These are just the generic benefits of implementing off-the-shelf software features. If you look into the pros and cons of building vs buying software for specific industries, the benefits multiply.

Why reinvent the wheel?

However satisfying it may be to build it from scratch, it’s important to ask whether it’s justified or whether it’s a matter of pride coming before business priorities.

Here are a few of the questions you should ask yourself:

• What is the cost-to-company in developer hours, testing, etc. compared to using a ready-built solution?
• How much longer will it take to build from scratch?
• How much experience do your team members have building this type of product or feature?
• What are the industry standards and user expectations of this type of product or feature, and will you be able to reach them?
• Is there an opportunity cost to waiting to launch a feature?
• What are the pros and cons of choosing monolithic vs microservices architecture?
• If you have very specific needs, is there an existing software option available that allows the level of customization you require?
• Will you have the capacity to maintain, update, optimize, and scale this product over time?

If, in the course of answering these questions, you’ve come to the conclusion that integrating pre-built solutions into your product isn’t such a bad idea, after all, congratulations – your job is about to get much easier.

If you’re looking to build in-app messaging and chat, voice calling, and/or video chat capabilities into your app or web platform, why not try Sendbird?

For more on this topic, read Don’t try this at home: Why software engineers shouldn’t build chat in-house.