It is inevitable that an enterprise will one day ask, “is it more cost-efficient to build or buy this piece of software?” 

• To build means to create the software from scratch. Doing this requires a team of software engineers, maybe a product person, testers, a budget considering total cost of ownership, diligent roadmap planning, and a whole lot of time set aside to maintain the software post-deployment.
  
• To Buy means you work with a vendor that has already built the software you need. They thought of all the nuances, squashed the software bugs, are constantly looking for ways to improve their product and have dedicated support to keep their clients happy. 

Both options come with pros and cons. We understand that. And we understand that this decision is not an easy one to make. In fact, we just went through this same process. After our map solution provider increased their pricing, our engineering team asked one pivotal question: Do we continue using this provider as a vendor, or do we build more of the solution ourselves? 

To dig more into the Buy vs Build dilemma, I sat down with Evan Martinez, one of Dispatch’s software engineers to learn what went into this decision.

Q: How long have you been with Dispatch and what is your role here?

I have been at Dispatch since October 2018. I originally came on as a Junior Software Engineer and now I am a Software Engineer II which is essentially a Mid-level software engineer. I’m on the Rapid Response Team which is the team that works on immediate need software fixes, smaller product enhancements, and proof of concepts.

Q: If an IT team came to you and asked for your advice on build vs. buy, what would you say?

It really depends on the timeframe for the IT team and the costs associated with building the product. From a timeframe perspective, if a small IT team can build something in 1 month, and it brings benefits, build it. It can be fun and you can learn a lot in the process. From a cost perspective, while you may be able to build it quickly, there are many costs associated with operating and maintaining homegrown solutions.  For example, the cost to host and maintain the software on servers may be a massive expense to the business. In that case, it may make sense to buy. 

Q: What are some of the hidden costs of building software? 

There are a few costs that at times are overlooked. Most teams are aware that server costs are always a lot – unless you have spare idle compute capacity in your own internal servers. Another cost is whether you need to upgrade those servers in order to run the software efficiently, for example, do you need a lot of RAM, for the software to function correctly or at all. Another thing to think about is software licensing. For instance, some software that you build upon may have license limitations or requirements related to open source software. If it does, the lawyers should weigh in on how that exposes you as a company. 

Q: You worked on Dispatch’s new map functionality. Prior to this new map, Dispatch used a well-known service provider for this. Why?

Our previous map provider is used on many platforms beyond our own. For Dispatch, the decision to switch from that provider over to an open source provider was made for two reasons. The first was the cost. They decided early last year to change its pricing model which tripled our cost. The second reason was that the engineering team is always looking for challenging projects to work on and I have been thinking for a while that it would be fun to work on a new map solution. This idea came up right around the same time that the cost was going to go up so it was perfect timing and we decided to launch the project.  

Q: What was your mindset and overall approach to the new build?

My goal was to get a proof of concept out as soon as possible so that our project manager and others on the engineering team were aware of what we can do. The question that needed to be asked is can we get our information for maps from a free or open source framework instead of our previous provider and how easily can this be done? We then went through and did our due diligence to determine which open source platform would work for us. This allowed us to set a timeframe and project scope.

Q: What were some of the challenges that came up for you and the team during the build process?

One of the tricky parts is that our team is responsible for quickly responding to issues as they come up. We had to figure out how to manage our day-to-day tasks vs our larger projects like this open source map project. We also ran into unexpected issues that ended up costing us more than we originally planned. For instance, our previous provider has functionality such as geo-coding for latitude and longitude – we had to use a combination of paid services as well as what we were building to make that work. 

Q: With the map feature being a critical aspect of Dispatch, what steps were taken to make sure this change would be smooth for the end-user?

Our baseline was to have the map look and feel very similar to what users had grown accustomed to. Once we were finished, our project manager looked at what we developed and her immediate reaction was that while the functionality was optimized well, customers would not like how it looked. It did not have the same appearance that our previous map had. With that feedback, we went back to make visual changes so that the customer experience would be flawless.

Q: Have you seen any major issues or problems with the build?

Originally I expected to be working on the map more. After 8 months since the new map was released, the map is humming along nicely. This is a testament to both our own coding ability, but even more so a testament to this open-source platform. One of the best things about the open-source platform is that a great number of engineers are continuously working to improve the map. 

If on the other hand we went and paid for proprietary software we would be limited in the ability to make changes. If we did make changes we would likely run into more issues and bugs along the way. 

Q: After building this new map what have the results been like for Dispatch? 

Costs have been significantly reduced and the cost of development paid for itself in just a few months. Had we stayed with our previous provider we would not be able to adapt to customer needs. We had customers that wanted to have a map that was able to view census tracking and grids. Our team was able to build that in a timely manner.