Build vs. Buy? How Your Engineering Team Can Make the Right Choice

Most engineering teams opt to build features and solutions themselves. After all, isn’t the purpose of an engineering team to build everything?

Maybe not.

Mike Garrett, Engineering Manager at fintech startup MotoRefi, shares an alternative viewpoint. His team has learned that purchasing, instead of building, can free them up to focus on what matters most: building new features and things that actually help their company get a competitive edge.

In this interview, we cover:

• The difference between build versus buy in the software space
• The approach that MotoRefi has taken
• Factors that impact the decision to build or buy
• Tips to ensure your team makes the best choice

The conversation below has been edited for length and content. Can you explain what you mean when you say build vs. buy within the software ecosystem?

It’s a discussion that happens a lot within software engineering. Building entails having your engineering team gather requirements, spec out a custom feature your organization needs, and then build it. Alternatively, buying involves finding a SaaS product or company that has already made a solution that you can purchase and configure to meet the same need.

Where does MotoRefi stand along the spectrum of this decision?

Before joining MotoRefi, I never considered the buy option seriously, other than a few specific scenarios.

I thought it could make sense if a team was trying to build a small, specialized feature or a really large feature like a business CRM. But when it came to that area in-between, I never understood why a team would opt to buy. I thought if a company had taken the time to hire a team of engineers, then they should always have them build instead of choosing to purchase something.

But as the company has grown and as I’ve talked with others who work here, I’ve switched my mentality. I’ve realized that it makes sense to find software that’s already proven. If it already exists and is available, then your engineering team can quickly integrate to help move the company forward much faster. Because that’s basically the name of the game: speed.

Earlier on, the company had more of a build mentality. Our infrastructure had been transitioning to a Kubernetes cluster we maintained ourselves and a PostgreSQL instance that we managed. But the process of managing it ourselves showed us that we were almost spreading ourselves too thin. We couldn’t use the engineers who were on staff to build the new features we needed to keep up with the growth of the company.

Over time, we’ve transitioned more to buying rather than building because it gives us the ability to get the same things we were looking for — the same software, the same features, and the same availability.

For example, we’ve purchased client libraries that hook into our current back-end libraries and front-end languages, We were able to purchase, integrate it in, and get what we’re looking for while also being able to iterate on the features that make us different and help us get ahead of our competitors.

What are some of the main factors that play into your decision process of buying versus building?

Speed is key for a lot of engineering teams. You get the end product faster by buying. You don’t have to put it on your roadmap or create a project management plan. It’s something you can purchase, acquire, and integrate into your solution.

It also allows you to quickly iterate. There are SaaS products that you can buy through a monthly subscription, instead of committing to an entire year. You can drop out at any time. We use those as a quick prototyping tool.

For example, we’re looking at using Retool. It’s a software platform that allows you to drag and drop components into a canvas, hook it up to any data sources that you have, and quickly build out an application. We use it to integrate into our software development process to get feedback from our stakeholders before we use our engineering resources to actually build something out.

Many engineering teams can relate to the experience of spending months to build something, only to have it be scrapped or deemed obsolete because the customer has moved on. We didn’t want to be in that boat. We were looking for solutions that allowed us to get something in front of our customer quickly. That way we could ask “is this what you want?” and “is this how it should act?” before we spend our limited time building something in our custom CRM.

Another factor is that you get all the features you were looking for (if you do your due diligence) plus more because the product is based on more than just your company’s use case.

Plus you get a maintained software that has continuous updates without additional work from your team.

What are some tips for an engineer who is deciding between building and buying?

In general, my rule of thumb is to ask these questions:

If yes, then it’s worth it. That means that you can pay for the solution and get it instantly instead of hiring someone to work on the specific feature or task.

One of the greatest benefits is giving the engineering team more time on their hands. That allows them to focus on things that will push the company forward.

If you keep those two things in mind it helps the decision to be much more clear.

Does your decision to buy versus build change as the company grows?

A lot of these SaaS products provide a free tier which allows small companies (typically 0 to 25 people) to get the same benefits of the product without having to pay for it. In almost all those cases, it makes sense to just integrate those pieces into the startup’s platform. It’s especially great for solutions that would require a focused team of engineers to build it correctly.

For things like authentication or log aggregation for your company’s suite of services, you can integrate a low, free tiered SaaS solution. You can get all those benefits and it allows the developers to focus on building solutions that give the company a unique competitive advantage.

Our team at MotoRefi has grown so that we’re right on the cusp. We’re paying for the higher tier options, but not at the enterprise level. If we reached the enterprise tier, that’s when the cost would become too much, unless the company grew.

It can become a difficult decision to make. If we acquire this tool now, will it benefit us enough to still justify it a year from now?

This kind of purchase makes a tangible difference with how far we can push the company forward within the next year. As a company gets closer to a headcount of 500, it can be easier to justify purchasing a large platform.

Originally published at https://www.myhatchpad.com.