« Previously: Steps 1-3  

Step #4 – Calculate the break-even point

Armed with a fundamental system understanding along with knowledge of the capabilities that exist in the development team, it is now time to calculate the break-even point for building the software versus purchasing it. Calculating the break-even point can be tricky because there are numerous factors that come into play. Typical project failure points come from optimistic estimates on development time, firmware maintenance, and even component complexity.

The major business trade-off is time-to-market versus overall cost. Building a component may wind up being cheaper but take four times as long to develop. Is that an acceptable business trade-off or is getting to market king? To decide the answer, developers need to identify possible vendors for the firmware components, understand their warranties, cost, delivery dates, and any potential integration issues that could arise. The component cost to buy can then be compared with the estimated build cost and when compared with time, a break-even point can be determined.

Step #5 – Determine the build vs buy ROI

At the end of the day, the team needs to provide a solution that attempts to optimize the return on investment (ROI) that the company is making in the product. There are many ways that this could be looked at. First, one could look at attempts to minimize costs or secondly, to maximize sales. Over the product life-time, does the license fee associated with the purchased software cost more than building your own? Will more than one project need the same software component? Maybe the initial build costs are higher than purchasing the software but due to volume or the product roadmap it makes sense to invest in the engineers’ skillset so that the work can be done in house. There are many factors that need to be considered and while many view ROI as strictly a monetary return, a wider berth may be necessary to make the right decision.

Step #6 – Make the decision

At some point, the development team will need to decide if it's going to make or buy a firmware component and move forward. Sometimes the decision will be made simply on intuition. Other times the decision will be made because it would be really cool to write your own RTOS. For best results, though, attempt to use a controlled decision-making process. We’ve discussed a few steps that should provide some engineering or scientific thought into that process.

Making the decision to buy versus purchase firmware components can be a difficult decision to make. In many cases, the initial sticker price is a shocker and teams dive in to do it themselves without further consideration. The result in some circumstances can be delayed deliveries or even increased development costs. Following the steps laid out here can help turn the decision making into a more controlled and thoughtful process by taking into account the larger picture and not just short term cash flow.

Jacob Beningo is an embedded software consultant. He has published more than 200 articles on embedded software development techniques, is a speaker and technical trainer and holds three degrees, including a Master of Engineering from the University of Michigan.

This article was originally published on EDN.