Build vs Buy: A Guide to Implementing Smart Manufacturing Technology

To remain competitive, manufacturing teams need solutions that proactively produce insights from their manufacturing data. They face a key decision to either buy a solution or to build one themselves. Purchased MES, QMS, and PLM systems are commonplace in electronics manufacturing – as are customized integrations and internal tools that work just how a particular company needs to meet its goals.

As Don Brunnett, who previously ran data analytics teams as Director of Product Integrity at Amazon Lab 126 and VP of engineering at Western Digital puts it, “The internal team almost always wants to build.” What might seem like a “quick plumbing project” actually entails much more.

We sat down with three experts in the build vs. buy decision-making process for manufacturing software, based on their experiences, to get to the final answer: Should you build or should you buy?

7 Build vs Buy Factors for Manufacturing AI

1. Time to Value - How long until you get the benefit?
2. Integration - What systems does it need to work with?
3. Maintenance - What effort and cost will there be to support it?
4. Scalability - How can it grow with your business?
5. User Experience - Will the users within the organization adopt it?
6. Cost - What is the total cost of ownership initially and over time?
7. Improvements - How will you stay at the cutting edge?

3 Questions to Ask Before You Build or Buy Manufacturing Technology

Before you make a decision, it’s crucial to understand both what you need and what’s available on the market. Here are three questions every leader should answer to understand what their business needs.

What manufacturing problem are you solving? What value does that solution have to the business?

Any leader faced with a critical decision needs complete clarity on the problem statement. It can be tempting to jump to solutions first – particularly with shiny new technology – but starting with the problem statement is a fundamental that may expand the solution space in ways you didn’t expect. While there are certainly some manufacturing technologies that just feel like table stakes these days (MES, PLM, CAD), getting clear on the problem is critical upfront. Ideally, you’ll want the problem statement to be large enough to encompass a business metric or impact – versus just a tactical problem. 

How much customization do you need?

While we all like to think that we’re developing and producing unique products with unique challenges – how unique is it really? If your business is similar to others in your industry, you may not need a lot of customization. Having worked with customers across the industry building everything from implantable medical devices to motorcycles and smartphones – it is rare for a company to have a one-of-a-kind factory situation. 

Take time to truly consider if your business requires a highly customized solution.

How core is this system to advancing your technology or IP?

As an organization, you have a limited number of resources. Spend them focusing on building products that contribute to your core competitive advantage and revenue versus reinventing something that exists.

Speaking of focusing on IP, some leaders do get tripped up on this one. They mistakenly assume that the only way they can secure their IP is with an in-house solution. While securing your IP can be a requirement, don’t assume that third-party solutions are totally off of the table. Cloud-based and SaaS software is used for the world’s most sensitive data. Caitlin Curtis, Director of Strategic Initiatives at Instrumental, who ran multiple digital transformation projects inside multiple highly regulated aerospace companies, explains, “Even if you’re building your own software, you are likely still buying component software infrastructure to build it with – such as Amazon Web Services or Datadog.”

7 Build vs Buy Factors for Manufacturing AI 

Once you have answers to those critical questions – it’s time to start exploring the solution space – internally and externally. As you do, you’ll encounter at least seven key factors to consider in making your decision, which you can use to understand the pros and cons of different possibilities.

Time to Value - How long until you get the benefit?

There’s no two ways around it: developing in-house software takes longer than buying off the shelf.

Building a solution from scratch is a time-intensive process that involves hiring or repurposing talent, developing a roadmap, prototyping, and extensive testing before full-scale implementation. This long lead time delays the realization of benefits, potentially putting your organization at a competitive disadvantage. Before signing up to build your own system, make sure you have a realistic plan for the skills, people, and time needed to deliver for the organization.

Commercial software products offer immediate access to various features, enabling business value quickly. Caitlin told us, “Organizations often underestimate how much you have to build to get business value. Why not just focus on your business goal?”

Integration - What systems does it need to work with?

Greg Reichow, former VP of Operations and Production at Tesla and SunPower, says the answer to “How well will it integrate into other systems you have at your company?” is a crucial deciding factor in the build versus buy debate. 

If you’re looking to purchase a technology or solution – it’s important to understand what integrations are available, what integrations you can pay the vendor to build with professional services dollars, and what integrations you’ll need to build. You can cross-reference this with your list of customizations from the critical questions above and see where the gaps lie. 

When looking at building the solution in-house, don’t just assume the integrations will work themselves out. The expertise and capacity to tie into all of the systems may be limited within the company (if it exists at all). Also integrating between multiple custom-built technologies can be more nuanced than you might think – requiring changes on both sides for the systems to be able to talk to each other in the way that you need.

Regardless of build or buy, integrations should be automated and resilient – relying on the manual upload of.CSVs or a consultant to build a new script for every little change is not a recipe for success. Greg believes modular systems offered by third parties with open APIs offer the best of both worlds and are the most flexible for integration with existing systems.

Maintenance - What effort and cost will there be to support it?

Manufacturing systems are critical infrastructure and downtime is expensive. Any internally built system needs a dedicated team to address bugs, do software updates, ensure uptime, scale with the business, and extend functionality. As Greg sees it, “The challenge is: how long are you going to keep the team on this? If it’s indefinitely, that’s a high cost. If you scale down to maintenance mode, in 5 years you have an old system that doesn’t fit the business.”

When you buy a solution you are also purchasing maintenance and support. Since that maintenance and support can be spread over multiple customers, by definition it will be cheaper than anything you can do internally. Additionally, if you are a customer looking for a solution, you can negotiate Service Level Agreements (SLAs) with target response times and 24/7 support – something that might not be possible internally.

Scalability - How can it grow with your business?

For manufacturing technology – there are two types of scale to consider: manufacturing scale and organizational scale. Manufacturing scale is scaling to meet the manufacturing needs of the business – SKUs, volume, lines, factories. Organizational scale is scaling across your organization into different business units and potentially different functions – such as finance, operations, engineering, IT, logistics, and maybe even retail. Whether you build or buy a technology, you need to contemplate both types of scale. Typically purchased systems will have a leg up here, just because they are already built and in-market – so no investment is needed to achieve scale for your business.

Manufacturing scale is nothing to scoff at – but modern cloud technologies make this much easier than the old “on-premises” days. Off-the-shelf systems will come with scale from Day 1, so they won’t have to be built or rebuilt as your own operations scale. Typically they are already handling significantly higher volumes of data processing than you will need because they are doing so across many customers at the same time. If you are building a system, you’ll need to be very careful about thinking about that scale upfront.

In terms of organizational scale – we already discussed integrations (which are critical for tying into the system's other team's users), but you’ll also need to contemplate how to make it easy for other users in your organization to get access, login, get training, etc.

User Experience - Will the users within the organization adopt it?

The success of any software solution depends heavily on its adoption by the end-users. Custom-built systems often face user resistance due to user interfaces and workflows that are difficult to use. One would think that if you’re building your own software, that it would be perfectly usable for your team – the challenge is that you’ll likely be leveraging software developers who may understand very little about the users they are developing for and the problems they are trying to solve. It’s also very tempting to take useability shortcuts on tools for internal use (ask me how I know!) that never get fixed. In contrast, commercial software is typically developed with a focus on user experience, product teams who deeply understand their users, and typically significant iteration from earlier customers who are similar to you.

Here’s a tangible example. Instrumental has been working with a large networking equipment manufacturer for many years. They had already started building their own internal system to aggregate and analyze functional test data, with the idea that their large team of 15 or so data scientists would be able to use it to identify unique and valuable insights to improve their products and manufacturing processes. There are over a hundred engineers across the organization who could benefit from access to this data too. Unfortunately, the user interface was sparse: to pull data you needed to craft a SQL query. Let’s put it frankly: none of the 100 or so engineers wanted to learn to query the database, so instead, they emailed requests to the 15 data scientists for datasets they wanted to see. Instead of spending their days doing deep analysis of the data, many of them were consumed with daily requests from the rest of the team – essentially bridging the gap for having a poor UI. 

This customer bought Instrumental as a user interface on that dataset (plus an additional visual dataset), which freed up the data science team to focus on more complex analyses. A poor UI can be the difference between getting value out of your investment in tooling or not.

Cost - What is the total cost of ownership initially and over time?

While the initial outlay for developing software in-house might appear lower than purchasing a commercial solution, the long-term costs tell a different story. As Caitlin explained, when teams are contemplating building their own systems, “We have this strange idea that it is free. End users don’t see the pain behind building and maintaining the software. They don’t realize that they’re taking on an entire new business function and it’s overhead – which will have a very real cost.” The initial outlay for development could be more than $10M (see the example at the top of the article) even for something that appears relatively straightforward. Ongoing maintenance costs could be millions per year. And neither of these accounts for the work to make the system itself better over time.

Development delays, ongoing maintenance, and the opportunity cost of diverting technical resources from core business activities can quickly inflate the total cost of ownership of a custom-built system. Additionally, internally developed tools can be hard to navigate away from, due both to the sunk cost, internal champions, and the normal human resistance to change. Commercial software, with its predictable subscription fees, offers a more cost-effective and budget-friendly option over the long term – often enabling ROI very quickly.

Improvements - How will you stay at the cutting edge?

When you build a software system in-house, you are likely thinking only about today’s requirements. But in just a few years, the shiny new design, written in the latest best software language, with the cutting-edge technology may start to feel old and crusty. Greg Reichow described how important it is to consider how fast a tool will “age” – and with software – he believes it’s faster than many leaders think. Investing in continually updating an internal system can be very difficult to justify – and generally depends on how successful the initial implementation is. As we outlined above, there are a lot of things any system has to get right – including one built in-house – before it will make sense to continue investment. That creates a risk that commercial systems don’t have.

To remain relevant and competitive, commercial systems are constantly being updated, improved, evolved, and extended. If they aren’t, you have the option to switch to a competitor who is in a few years. Particularly in AI, where there will likely be many advancements in the coming months and quarters – buying a system may give you the greatest flexibility to take advantage of the highest value-generating technology available, at the speed that it’s becoming available.

Conclusion: Should you Build or Buy?

While building internal tools can perhaps be the right solution for companies whose unique, perhaps idiosyncratic systems require tailor-made AI integration solutions, the DIY approach offers a longer (and steeper) climb to achieving ROI, and the reallocation of resources and engineers away from work that enhances the company’s primary mission is a misfire. It’s the right solution if your business is unique enough that it’s the only solution.

While the allure of a perfectly tailored in-house solution is strong, the realities of software development often reveal a different story. By choosing to buy, operations leaders can avoid the distraction of non-core activities, focusing instead on what they do best: innovating and improving their products and services. Buying turnkey software offers a pathway to immediate innovation, operational efficiency, and strategic focus, allowing businesses to concentrate on their core competencies and competitive strengths.