Executive Summary
Business best practice dictates that organizations focus resources on areas that create market differentiation. Areas that are not a direct source of competitive advantage — such as enabling unique customer experiences or creating new revenue streams — are likely to be infrastructure or operational rather than strategic. Under this premise, most companies no longer create their own customer databases (CRM), resource planning systems (ERP), or build internal CI/CD tools. The majority of companies do not host their own email servers, websites, or internal storage databases.
However, many established companies built software update systems internally years ago to meet their immediate needs. As smart IoT products become the norm, software updates and device management have also evolved from technical afterthoughts into mission-critical infrastructure. For most organizations, deploying software updates increasingly falls into the operational category. The value of a software update is in the update itself, not the delivery mechanism. In rare cases, software update capabilities are central to product differentiation or revenue generation and may remain strategically justified for organizational focus.
Today, increasing complexity, regulatory pressure, cybersecurity risks, and business model shifts are forcing a reassessment: Should we continue building and maintaining the current software update solution?
This decision is no longer primarily about commercial license costs versus engineering salaries. It is a broader question about the total cost of ownership (TCO), encompassing operations, risks, strategy, and competition.
The strategic question: Is the method by which software updates are deployed central to your competitive advantage?
For organizations at this intersection, whether to maintain the current software update system or pivot, there are three key considerations:
- Measuring the total cost of building a software update system: The cost of an internally built software update system extends far beyond initial development. Direct costs include: engineering and product management resources; third-party libraries and security tooling; and ongoing feature development and compliance updates. Indirect costs add: site reliability engineering (SRE) and infrastructure overhead; cloud computing, storage, and network bandwidth costs; deployment failures and support burden; and bus factor risk (dependence on key individuals).
As fleets grow in complexity and scale into hundreds of thousands of devices, deployment error rates — even if low — translate into significant financial exposure. Unplanned truck rolls, customer dissatisfaction, service-level agreement (SLA) penalties, and reputational damage pose tangible costs. Regulatory requirements, such as the EU’s Cyber Resilience Act (CRA), Radio Equipment Directive (RED), and Network and Information Security 2 (NIS2), mandate audit logs, security-by-design principles, software bill of materials (SBOM) traceability, and demonstrable integrity of software updates. Retrofitting legacy systems to comply with today’s regulations often requires substantial investment. - Understanding the total value of a software update system: A software update system demonstrates measurable business value in two ways. Cost reduction includes reduced truck rolls, fewer support incidents, lower network traffic costs (via delta updates), reduced security risks, and avoided recall and compliance penalties. Revenue enablement facilitates faster feature rollouts, AI model deployment, subscription services, improved onboarding and adoption, and higher product lifetime value. For legacy organizations traditionally focused on hardware, software updates are often primarily a cost reduction mechanism. For software-driven or subscription-based businesses, software updates increasingly act as a revenue enabler.
- Weighing the risks of change against the risks of inaction: Replacing an existing software update system carries operational and organizational risk. Yet, so too does continuing to invest in an unstable or non-compliant system that may expose the company to greater long-term repercussions, including regulatory penalties and reputational damage. However, companies do not need to view change and inaction as a zero-sum calculation. For some organizations, a phased augmentation strategy, that is, enhancing existing systems with commercial components, may reduce transition risk while improving capability.
Whether internally built, vendor-purchased, or augmented, software update system investments will face ongoing strategic and budget scrutiny without a clearly articulated understanding of the above. Therefore, companies should employ a data-driven decision framework to evaluate the best strategic path forward for their software update system. A structured evaluation should:
- Determine whether the software update system is a strategic competitive advantage
- Quantify the full total cost of ownership (TCO), including direct and estimated indirect costs
- Assess cybersecurity, safety, and compliance exposure
- Evaluate long-term outlook against growth objectives, such as vendor lock-in and internal employee dependencies
- Model the final business value in clear financial terms
The analysis must be objective and data-driven. The optimal decision will vary by company maturity, product complexity, fleet scale, cybersecurity, safety, regulatory environment, and business model.
As with other infrastructure systems, whether to internally build, buy a third-party solution, or augment an existing software update solution is no longer a technical debate — it is a strategic, capital-allocation decision. Organizations that rigorously assess total cost, operational risk, and measurable business value will be best positioned to support secure, compliant, and scalable product growth in an increasingly regulated and software-driven world.
Software updates and IoT device infrastructure: Introduction to the considerations
When there is a novel internal need, the default answer in most companies is, "Can this be solved with something we already have?” The challenge's apparent novelty is a critical aspect. When the challenge is commonplace, organizations do not immediately assume they should solve it themselves; why would they when they can buy a solution that addresses it more effectively?
But when the challenge is niche or the company is entering unfamiliar territory, the propensity to solve it internally increases.
Leveraging software updates varies by company type
Today, smart products – or IoT devices – are the norm. From the front doorbell to advanced manufacturing robotics, nearly every product category includes a smart element with software at its core. Alongside the explosion of IoT devices, software and related device management evolved from a technical afterthought into mission-critical infrastructure.
When and where a company entered the smart IoT transformation directly affects where its software update and device management infrastructure are today. When it comes to software and IoT device management, there are these two generic groups: 1) new entrants, representing the new generation of companies or products, and 2) incumbents, representing the traditional companies with histories pre-IoT.
New entrants default to buying infrastructure solutions
First, there is the new generation of companies, reimagining solutions, hardware, and software from scratch. Companies building new smart products default to buying infrastructure solutions. Very few new entrants build their own server farms, CI/CD pipelines, integrated development environments (IDEs), or similar solutions themselves. For new entrants, the default choice is to buy, rather than build, commodity solutions.
Improving developer efficiency and reducing time-to-market are critical objectives for new entrants. All resources are focused on building the new innovative product and features that will make it a success as quickly as possible. Time is of the essence, and anything that is not a competitive advantage to the business and its product should be outsourced. Building a new solution is simply too costly and time-consuming. This applies to software update management; it doesn’t make sense to build their own firmware/software deployment solution. For these companies, the main reason for buying solutions points to reduced time-to-market.
Incumbents with legacy solutions evaluate options
For more established companies, the situation is not clear-cut. Traditional sectors, like automotive, manufacturing, industrial, and healthcare, usually fall into this group. Historically, these organizations focused on physical products, manufacturing, and components, like building vehicles in an assembly plant; their history extends far before software or IoT entered the marketplace.
Many established companies built internal software update systems years ago to meet their immediate needs. In fact, most incumbents have two or more software deployment systems, depending on the company's size and age. For example, one leading organization disclosed seven different software update systems to date. These companies are usually proponents of building or maintaining a homegrown solution, typically citing savings on license costs as the key justification.
To build or buy software updates infrastructure
Lacking the long history of incumbents, new entrants entered a more developed, less novel IoT market and, in favor of faster time-to-market, typically bought infrastructure solutions.
Incumbents, however, possessed a history and adapted to an IoT world while it was being developed. Incumbents more frequently started in the novelty zone. And for infrastructure solutions such as software updates and IoT device management, these organizations leveraged open-source offerings to build their own bespoke infrastructure, often referred to as “homegrown solutions.”
Over time, the novelty question re-emerges for incumbents as leadership emphasizes core business differentiation. Should the organization continue to maintain its homegrown solution? Should it consider buying an externally available offering? Or, is the best solution an augmented, mixed approach?
For both groups, the decision on whether to buy or build a solution is more nuanced, and more factors beyond merely time-to-market and license cost should be considered. This paper discusses the most important factors companies should consider when deciding whether to buy or build an internal solution. By using these key factors, organizations can follow the methodology outlined to evaluate and reach the best conclusion for the company.
The evolution of legacy software update systems
Regardless of type, internally built systems typically go through the same lifecycle and follow the same path.
When building a new smart product for the first time, enormous challenges emerge. First and most importantly, a new product faces a continuous stream of issues and improvement requests from customers. All the team’s resources are focused on resolving product issues and successfully launching the product to the market. In practice, only what is launch-critical becomes prioritized during the pre-launch stage. Cybersecurity and system management are afterthoughts; software updates are addressed only when needed to remediate a product issue.
Requiring a critical infrastructure component “yesterday” is not uncommon during the pre-launch stage. In these cases, the process defaults to using open source components and stitching something together in a hurry, or risking product launch delays. Thus, a couple of selected engineers are tasked with resolving the remaining infrastructure challenges and developing a solution as quickly as possible to not delay launch. As a result, barebone homegrown solutions see the light of day, becoming the infrastructure on which the newly launched product relies.
Given the imminent product launch, both security and device lifecycle challenges are solved in a rush and haphazardly. The whole device lifecycle has not been properly thought through.
Infrastructure failure becomes a looming challenge
Given the typical background of how homegrown software update systems begin, it is no surprise that early versions are fragile and insecure. The first version of a homegrown software update solution focuses on the product. How do we update the device? Once this problem is solved, it is easy to consider all software updates solved. The team simply needs to connect the product to a backend update solution server, and everything is ready to launch.
In reality, however, the backend server typically constitutes 80-90% of a software update solution. And, the backend server is where most homegrown software update solutions struggle the most.
Updating a single product is easy. Updating a large-scale fleet is not. Add product versioning, complexity, environment or connectivity variants, or risk management and security parameters, and the challenges expand exponentially. Without proper backend management capabilities, fleets quickly end up in unknown states, where both deployment success and device inventory are unknown. The backend server is the brain that makes complex decisions. Yet, in most homegrown systems, the device client serves as the brain and performs the actual update.
In real-world examples, everything from unencrypted file transfer protocol (FTP) solutions to a myriad of bash scripts so large and complex that no one really understands them characterizes the homegrown systems supporting new IoT products. As with any first version of a product, the software update infrastructure is buggy and fragile. Over time, alongside the product, homegrown systems tend to improve based on the amount of time and resources invested in the infrastructure.
The horror stories are real. In one scenario, a company went out of business because its infrastructure systems were so poorly designed. In this example, the company failed to account for product shelf time. Due to numerous new features and rushed deployments early in the product lifecycle, the company accidentally broke the product’s backward compatibility. A significant portion of their products was rendered unusable! When a customer activated a new product, the software installed during manufacturing could not communicate with the new infrastructure to receive the necessary updates and activations.
Additionally, deployment success rates are, for the most part, unknown, along with the reasons for errors. Most homegrown software update solutions lack security-by-design principles. System management engineers are not developing these bespoke solutions, so the foundation upon which the platform is built and to be improved upon is almost always unstable and seen as an (undocumented) black box. Some challenges are expected and accepted as normal, but when issues escalate, the full extent of the challenges can come as a surprise.
The inflection point is where sufficient support prompts a re-evaluation of the current plan (maintaining the homegrown system) against alternatives (shifting towards a vendor-supported solution).
Reaching the inflection point: Significant gaps emerge
Over time and with proper resource allocation, most homegrown software update solutions reach a point where the company is satisfied with their performance, at least to the extent that upper management does not receive complaints. However, the software update solution, like any product, needs to evolve to support new use cases and requirements. It needs to be updated with security patches, applications, and operating system upgrades. It must comply with ever-evolving security and regulatory requirements.
Technology advancements move much faster than homegrown systems. It is often the case that homegrown systems cannot support containers because they were designed before containerization became widespread. Or, also common, the homegrown system is designed to deploy whole new images (in megabytes and gigabytes), even though the required software change might be only a few bytes or kilobytes; the result is wasted time and unnecessary network traffic costs.
Given the often reactive way homegrown systems are built, it is also common for the devices it manages to quickly end up in inconsistent states. Where are the devices? What version of software are the devices running? Which needs updates? Were the updates successful?
At some point, the homegrown system requires serious refactoring to meet the current business needs and future sustainability – the inflection point. Addressing new considerations, such as regulatory requirements under the EU Cyber Resiliency Act (CRA), is a clear example of how infrastructure and its documentation must evolve. What was once “good enough” is no longer sufficient. Infrastructure must improve, and in some cases, quite significantly.
As smart products proliferate in societies, regulatory bodies will instill ever more compliance guardrails to ensure safety and security. In the European Union, regulations like the CRA, Network and Information Security Directive 2 (NIS2), and Radio Equipment Directive (RED 2014/53/EU) are prime examples. The regulatory requirements associated with offering smart products will only increase, making it harder and harder to ensure compliance without a proper software update system, APIs, audit logs, and reliable reporting mechanisms.
Faced with these challenges, companies must decide whether to (re) build or buy infrastructure solutions.
The key question: Is the software update system differentiating your business?
It is considered a best practice in business to focus all efforts and resources on competitive advantage – that which differentiates a company or offering and drives success in the marketplace. Following this strategy, OEMs should optimize time and resources on the product and experience around it. Valuable resources, from leadership to engineering, should focus on the product.
Extrapolating priorities further along the strategic importance and competitive differentiation facets yields the following matrix.
.png?width=1611&height=1043&name=Strategic%20Valuation%20Framework%20(1%20Icon).png)
Breakdown of the quadrants:
1. Strategic Differentiation (High Importance, High Differentiation)
- What it is: The "crown jewels." These are capabilities that directly drive customer purchasing decisions and cannot be easily matched by rivals.
- Strategic Action: Aggressively Invest & Protect. Allocate the majority of your resources, budget, and talent here to widen the gap between you and your competitors.
- Who is responsible: In-house talent. Keeping this internal protects your intellectual property and unique advantage. You maintain absolute control over your core competencies.
2. Strategic Parity (High Importance, Low Differentiation)
- What it is: "Table stakes." These are features or capabilities that are absolutely critical for doing business in your industry, but everyone else has them too (e.g., standard customer service, core software features).
- Strategic Action: Maintain & Optimize. Keep these at a high standard to avoid falling behind, but do not over-invest in differentiating them. Use cost-saving measures or automation where possible.
- Who is responsible: Strategic Partner. You share the burden of critical infrastructure with an expert third party. This keeps you compliant and functional without draining internal focus from innovation.
3. Commodity Niche (Low Importance, High Differentiation)
- What it is: Unique capabilities that set you apart, but do not move the needle for the broader market. These often represent highly specialized services, obscure product features, or "hidden assets".
- Strategic Action: Leverage or Divest. Either monetize these within a specific target market (e.g., an upsell or a niche campaign) or scale back investment to free up resources for other areas.
- Who is responsible: Internal talent or strategic partner. This depends. For example, if the niche capability is highly technical or risky, use a specialized partner; if it is easy to maintain and yields high margins, keep it internal. Or, at a small scale, it might be easy to keep it internal, whereas at a large scale, it makes more sense to rely on a partner.
4. Commodity Support (Low Importance, Low Differentiation)
- What it is: Baseline operations or generic product elements that neither distinguish you nor matter significantly to the core customer experience (e.g., basic office supplies or standard administrative tasks).
- Strategic Action: Outsource or Automate. Minimize your internal efforts and investment in these areas. Outsource to third-party vendors to reduce costs for the business.
- Who is responsible: Outsource. Standard operational tasks should be completely handed off to low-cost vendor models to eliminate unnecessary expenses from your business.
Today, almost no one is hosting their own email server. That is a no-brainer, and clearly falls within the Commodity Support quadrant.
When analyzing software update infrastructure, follow the prioritization matrix. For some companies, the software update system is considered “their secret sauce,” like email servers are for Google, or car updates for Tesla. Although neither is core to the company's main value, both are likely high-margin differentiators and fall in the Commodity Niche quadrant. If the software update infrastructure is not a competitive advantage to the business, it is most likely in the Strategic Parity or Commodity Support quadrants.
Jeff Bezos is famous for saying, “You should only focus on making your beer taste better.” This refers to the fact that German breweries that continued to generate their own electricity lost out to those that switched to buying electricity from the grid. The same applies to any solution, whether it is low-level infrastructure tools or higher-level marketing, sales, and customer relationship management platforms.
Software update system: An evaluation guide
Regardless of the end result (building or buying), the decision requires a proper analysis. Most infrastructure decisions fall into the Strategic Parity or the Commodity/Support quadrants. OEMs must honestly assess where the decision falls and analyze options accordingly. Identify the benefits and risks of each option; weigh the different arguments, risks, and benefits against each other; and draw a conclusion based on the data.
In IoT, many infrastructure decisions are made on the fly. Under pressure to launch a new product on time, any challenges, including infrastructure issues, must be resolved as quickly as possible. As a result, many decisions are unfortunately based on gut instinct. Justification and supporting data only emerge secondarily. Those closest to the original decision face the greatest challenge in making a new, unbiased decision, as human nature dictates. But as the market and regulations continue to evolve, it becomes essential to future-proof critical infrastructure. The company deserves it, and the product’s success relies on it.
Additional resources: Appendix A, B, and C offer a list of common benefits and risks to building and buying solutions, followed by a scoring and evaluation example. Consider the areas of interest to your company, score them as shown in the example, and see the unbiased results.
The top two most important areas to consider
The list of factors to consider is extensive, and prioritization is critical. Based on market insight and real-world examples, the following are the top two most important areas to analyze.
In the end, defining the total cost of ownership and business value is the goal. When done well, the result is not only more nuanced than time-to-market or license costs, but also provides a solid foundation for the company and product to grow.
#1. The costs of a software update infrastructure
Any infrastructure solution incurs roughly the same costs, such as labor, maintenance, and support. Firstly, costs should be broken down into direct and indirect expenses.
Direct costs are expenses directly attributed to the specific solution. If the solution ceased to exist, the costs would also disappear. For infrastructure solutions, direct costs often include:
- Personnel cost: Salaries, pensions, benefits, etc., for engineering and product management, if one exists.
- Core license costs: Subscription costs for any third-party libraries or solutions used.
- Supporting license costs: Subscriptions associated with the solution, such as security solutions, common vulnerabilities and exposures (CVE) scanners, or penetration testing tools.
Indirect costs are expenses necessary for overall operations or business. These costs are difficult to attribute to one specific product or project.
- Personnel costs: Salaries, pensions, benefits, etc., for the site reliability engineering (SRE) team responsible for hosting the service.
- Infrastructure costs: Costs associated with delivering or maintaining the solution. Cloud costs, including traffic, storage, and computing, are often a significant cost, especially in the era of AI.
- Unintended costs: Consulting, support, or other unforeseen repercussions of managing, maintaining, or utilizing the solution
To break down costs to the solution level, leverage managerial accounting or activity-based costing, which are standard practices in accounting and finance. For example, if the full cost of an SRE employee is $200,000 and the employee is at full capacity managing five services, the cost per service is $40,000 per year. Or, if a company deploys 200,000 software updates in a year, the cost for the SRE employee is $1 per deployment. A similar analysis should be conducted for all stakeholders who spend time on software updates. This type of internal (indirect) pricing calculation should be conducted to more accurately allocate the costs for the specific solution in question.
Choosing to build an infrastructure solution or buy one doesn’t change many of these costs; it just shifts who bears them.
When buying an infrastructure solution, the buyer’s costs are predictable and easy to calculate. There are few, if any, additional costs beyond the monthly (or annual) subscription fee. The majority of the costs associated with the solution are incurred by the seller; they are responsible for the development, maintenance, support, and more, for their product. These costs are spread among the seller’s customer base, and the buyer incurs only the costs of accessing or using the product.
When building an infrastructure solution, the cost structure is much more complex. Infrastructure solutions are generally not differentiated; as a result, the builder is not selling the solution to create market value or generate revenue. Therefore, the builder becomes both the seller and buyer of the solution, both creating and consuming it. Building an infrastructure solution incurs both direct and indirect costs.
In addition to direct and indirect costs, the organization may incur intangible costs associated with the infrastructure decision.
The cost of change: Managing risks
Change is difficult, and it grows harder over time. Change disrupts established processes and procedures, forces learning or relearning, and introduces uncertainty and risk for the organization. The fear and risk of change are strong, whether replacing a built solution or a third-party offering.
Yet, the reason to consider a change is also invaluable. The most common reason to consider a change is to bridge the gap between what exists today and the desired or ideal state. In this type of scenario, there is a cost to both sides of the change: inaction incurs the existing costs, risks, and challenges of the current situation, while action entails the costs, risks, and challenges of undertaking something new and unknown.
Common examples of the costs of inaction include:
- the cost associated with operational downtime due to a bricked device,
- the cost of fixing a bricked device due to improper deployment,
- the cost of deploying a security patch late,
- the cost of failing to comply with regulations or SLAs, and
- The cost of brand, trust, or reputational damage due to poor products or performance.
For example, there is a cost associated with deployment errors in software update solutions. Worst case, a device is bricked and rendered inoperable. Or deployment errors leave a device unusable, requiring on-site service to fix it (unscheduled truck rolls). Deployment errors can lead to instability, service degradation, and customer dissatisfaction; if repetitive, deployment errors eventually incur brand and reputation damage costs.
Today, most companies operate at a deployment error rate of 10% or less. At this rate, if there are 100,000 devices in a fleet, approximately 10,000 devices will have a deployment error – receiving the wrong payload, a failed update, or an unknown issue. As a result, the organization will incur costs to address the 10,000 devices that failed to update.
Identifying the cost of deployment errors is critical, as the error rate is the main driver of considering a change – switching from a suboptimal to an ideal software update solution. The costs are specific to each company and depend on the product(s) to be updated, associated SLAs and contracts, and the value of the product to the company and related end user. In other words, the tolerance for deployment errors for a low-cost, low-value product is much higher than for a high-cost, mission-critical device.
On the other hand, common examples of the costs of action include:
- the cost of the new solution (i.e., licensing, infrastructure),
- the cost of implementing a new solution internally (i.e., operations, process),
- the risk of implementing a new solution (i.e., issues, failures, instability), and
- the risk of introducing a new solution (i.e., internal, political, reputational).
Many organizations consider the costs and risks too high to even consider a new solution for existing products; for this reason, very few organizations replace the software update solution for fielded product fleets, and more organizations evaluate the software update mechanism when planning greenfield projects. If, for example, the organization is relatively static, not agile, and lacks a history of significant change, there is considerable risk associated with switching software update solutions.
For either path, there are costs associated with the change, which should be included and weighed in the overall analysis.
Evaluating risks: Opportunity costs
Every decision involves opportunity costs – understanding and assessing the value (cost) of the next-best alternative to the decision.
Resource allocation
First, building a software update solution – allocating resources (time, effort, and money) to it – possesses a clear opportunity cost: the value of using those resources for something else. If the software update system is critical to the business and increases competitiveness (Competitive Niche quadrant), the opportunity cost is low; the software update mechanism is highly valuable to the company. Conversely, if the software update mechanism is more of a commodity (Commodity/Support quadrant) or table stakes functionality (Strategic Parity quadrant), there are other areas where allocating time and resources will yield a better return; in these cases, the opportunity cost is high.
Alternative costs are important, but often overlooked.
Creating dependencies: Employee lock-in or vendor lock-in
Another type of alternative cost is the future opportunity costs. Where resource allocation focuses on the alternative costs incurred today, future opportunity costs also evaluate the decision's future implications.
First, building a software update mechanism not only requires resources today (to build) but also resources in the future (to maintain and support). Future opportunity costs are the resources required to maintain and support the software update mechanism throughout its use.
As a result, most homegrown systems – software update mechanisms or others – rely heavily on a few key employees. Regardless of the type of solution, the team that built it becomes critical to its ongoing operation. Any commercial software solution follows the same pattern: the co-founders or initial engineering team are paramount to the solution's operation in the early stages. Only in the later phases of a company, with growth and larger teams, are proper documentation and redundancies implemented.
However, unlike their commercial counterparts, internal systems typically remain undocumented. There is rarely a roadmap for an internally used system; security and engineering best practices are rarely audited, even when followed. Companies are highly dependent on the solution’s builders and therefore face a high risk of the bus factor. To alleviate this level of dependence, the internal solution must be documented and socialized. The company should create “backups” or “redundancies” for the internal knowledge, skills, and expertise required for the internal solution to operate.
Similarly, organizations can become highly dependent on third-party offerings. For example, the hyperscalers were not cautious about vendor or service-provider lock-in and ended up with so much dependency on proprietary technology and APIs that it was impossible to change in the future. In choosing a vendor, whether a solution or a service, organizations must also analyze the future flexibility or dependency and inflexibility of using that vendor. To mitigate vendor lock-in, organizations should prefer open solution offerings. For example, open core software solutions offer reduced switching costs and future lock-in should the organization decide to change in the future.
Both situations entail future opportunity costs for the organization. Future resource allocation and the risk of critical employee dependency are implicit costs of the organization and the homegrown solution. Selecting a highly proprietary third-party solution directly limits an organization's future flexibility and, as a result, foregoes possible alternatives (implicit costs).
#2. Future-proofing infrastructure: Continuous improvement is required
It is easy to underestimate the complexity of a robust and secure software update system. Performing a software update, transferring software from one place to another, is not complicated in a rudimentary sense. And, in the past, the software update mechanism survived despite being mediocre.
Today, however, the technology landscape has significantly increased the requirements for a robust, secure software update solution. The software update system must handle a multitude of nuances as the products and technology it facilitates continue to advance. The variety of environments in which devices are deployed alone is one example of the complexity an enterprise-grade software update solution must handle.
- Network: Over-the-air, air-gapped, segregated, and offline environments
- Connectivity: Reliable, intermittent, or non-existent across the internet, cellular, or satellite
AI, ML, and edge computing add another layer of complexity. More commonly, organizations rely on their software update systems to enable new technology (e.g., AI algorithm updates) and revenue streams (e.g., AI model updates). Traditional companies, such as automotive and heavy machinery, also leverage the software infrastructure to deliver superior user experiences (i.e., more frequent upgrades) and reduce operational costs (i.e., reducing truck rolls caused by deployment errors).
As with any historical technological advancement, the corresponding security and regulations also evolve. Proving compliance with many of today’s regulations and standards requires clear and prescribed functionality from the software infrastructure on which the product relies.
Security and regulatory compliance
Over the last few years, new regulations have been introduced in almost every region of the world. The European Union’s Cyber Resilience Act (CRA) is particularly notable for its broad scope. The CRA, which is now part of the Conformité Européenne (CE) approval process, applies to nearly all products sold within the European Union (barring named exceptions). The CRA redefined what is required of an organization’s software update system: a robust, secure software update solution is no longer a nice-to-have convenience, but a must-have to maintain market access.
At the same time, features that were once considered “advanced use cases” are now operational table stakes and expected from all OEMs. Multi-factor authentication, federated secure sign-on (SSO), and role-based access control (RBAC) are security best practices; all solutions, whether purchased or built, are expected to adhere to these principles. Deployment phased roll-outs, signing, integrity checks, automatic retries, and resume download are required operational safeguards; a purchased or built solution that implements phased roll-outs ensures the stability of new updates while managing enterprise risk. Real-time inventory, audit logs, and end-of-life device commissioning not only provide the visibility OEMs need to manage product fleets but are also fundamental to security and compliance.
The list of requirements for a secure, robust software update system is lengthy. But to ensure that only the right person can deploy the right software to the right device, the capabilities and functionality must come together. Whichever direction an organization chooses – to build a solution in-house, purchase a third-party offering, or augment between the two – the final infrastructure must meet the requirements of operating in today’s environments, applications, and in the face of any adversary. When weighing all the factors that go into such a crucial system, the costs of building an in-house software update mechanism that meets the expected operational and compliance levels are high.
As smart products infiltrate more of society, and likely soon the human body, more will be demanded of the software and the infrastructure on which it relies. Further scrutiny and regulation can only be expected to ensure the safe and secure use of technology. To best prepare for the future, the software update system must serve as a solid foundation, one that can be extended, adjusted, and adapted. Whether buying, building, or augmenting, it is certain that more will be required of the software update solution in the future to meet tomorrow's requirements.
The importance of identifying the business value
It is clear there are benefits and risks regarding the decision to build or buy an infrastructure solution.
Proponents of in-house-built solutions lead with the sunk costs already incurred, typically to protect the project. Interestingly, an industry survey uncovered that organizations choose to build in-house solutions, not because it is the best fit, but because they can. Or, on the flip side, in-house-built solutions tend to suffer from a “not-invented-here” syndrome.
On the other side, proponents of purchasing infrastructure solutions are often change agents in the organization. Newly hired employees are a clear example, entering the company with relevant experience and examples from other organizations with well-functioning infrastructure setups. These employees tend to want to replace existing solutions when they see a gap or when there is sufficient value in optimization.
Regardless of existing predispositions, every organization owes it to its stakeholders to take an objective approach, analyze the situation, and choose the path with the best data-based return.
Proving value to secure the budget
Software and software update solutions can be more challenging than other infrastructure solutions, depending on a business's nature and history. In companies with a history of manual updates, such as onsite technician visits or service appointments, the idea of remotely updating the software and devices might be unfamiliar. In other companies, software is an augmentation to physical products and is freely given to users; only when analyzing the inherent costs of building and maintaining the software and the infrastructure to support it does the free software model become problematic.
Regardless of the decision, a budget is required. Whether paying for engineers, licenses, or services, resources are required. When it is time to secure the budget, management will inevitably ask for evidence of the business value of the effort or solution. Every expense should be justified through the lens of the business to ensure optimal resource usage. The larger the budget, the more scrutiny applied. Each expense must deliver revenue or benefits that outweigh the total costs. Therefore, it is in the organization's interest to have a clearly defined business value that the proposed solution is expected to deliver.
The business value of the device management system
The software update mechanism is the most critical part of a larger system, the device management infrastructure. As such, it is often the first aspect organizations encounter when managing their device fleet. There is a new software update, and it needs to be deployed to the products already in customers' hands.
The business value of the software update system, and thereby the larger device management infrastructure, is realized through two channels:
- increasing revenue and
- decreased expenses.
The software update system must deliver either or both.
Realizing cost reductions through the software update system
Most incumbent companies entered the smart IoT world by market force. From coffee makers and health wearables to thermostats and cars, smart IoT technology has invaded nearly every aspect of daily life. Incumbent companies adapted as a necessity for survival, but most have not been able to adjust their mindsets or business models to the new reality. Incumbents still sell a hardware product as they have done forever, and the related software is a necessity to earn the sale, but not necessarily the focus. In these scenarios, one must consider the costs that can be saved by adopting a secure, stable software update system.
Typically, a secure and robust software update system delivers cost reductions through reducing or minimizing:
- Unscheduled field service calls (i.e., truck-roll costs, onsite technician visits)
- Customer support calls and issues
- Issues related to software glitches (i.e., No Fault Found (NFF))
- Satellite and cellular traffic costs (i.e., smaller data transfers)
- Costs associated with bricked devices
- Costs associated with product recalls
- Costs associated with identified security breaches, exploits, and known vulnerabilities
- Costs associated with brand damage due to any device issues
Generating revenue through the software update system
At the other side of the spectrum, new, younger, and technology-centric companies are typically software-native. These companies understand the value and costs of the software associated with the physical product, as well as the nuances required to deliver value from the software in a cost-effective manner. As a result, nearly all companies in this group adopt a recurring subscription business model. Customers pay for continuous updates, in turn, supporting the continuous development and release of software for its products and underlying infrastructure. It is also common for these companies to focus less on the hardware being sold and the value of the software-hardware product as a whole, such as the amount of electricity saved, the number of vehicle license plates identified, or the amount of tonnage excavated. For these companies, software and hardware work in tandem, and the value of the product as a whole is priced strategically at the outset to fund both elements – hardware and software.
For these types of companies, the software update system is a revenue enabler. It is the backbone of the product that allows the company to adjust without changing the physical product.
Typically, a secure and robust software update system delivers revenue generation through enabling:
- Customer onboarding, troubleshooting, and usage
- Faster iteration and innovation (i.e., beta testing, field testing)
- Tiered subscription offerings (i.e., advanced features or add-ons)
- New features and offerings (i.e., purchasing new capabilities)
A proper software update solution enables and unleashes revenue generation and growth. In the generation of AI, ML, and edge computing, software update systems already enable these companies to add, adopt, and improve AI and software across their product fleet.
To determine whether the software update system is a revenue enabler, a cost reducer, or both, the organization must first identify all stakeholders who will benefit from a secure, stable software update system. Gaining access to the right software for the right product is the initial element, but it also involves seamless updates to ensure the product remains functional, superior support for issues, and protection of safety and security throughout the process.
Once stakeholders are identified, the organization should translate the benefits from the software update system into monetary terms. For example, to save costs, reducing the number of truck rolls is a very common lever. But when evaluating truck rolls holistically across direct, indirect, and alternative cost parameters, many benefits emerge. These benefits can also be translated into value and, thereby, justify the investment in the software update system.
Additional Resources: Appendix 4 provides an example spreadsheet that presents the values and calculations for common benefits and the possible total business value.
Considering an augmentation approach
The question of whether to build or buy a solution tends to be a binary discussion. But the augmentation alternative also deserves consideration. An augmentation approach involves a company enhancing its current solution by purchasing a solution to bridge the gap between what exists today and the desired end-state. The augmentation alternative is especially relevant in situations where the risk of change is high or intricate and complex operational processes exist.
Typical examples of areas of improvement in an augmentation approach include:
- Ensuring compliance with a corporate-wide standard through a cohesive, standardized, and more secure way of deploying software updates via an abstraction layer for the software update process across all systems.
- Improving administration and management capabilities to control, track, and audit user access, actions, and changes at the device level. Control, documentation, and auditability are common regulatory requirements, including with the EU CRA.
- Improving insights through deployment analytics, such as deployment errors, time to deploy, and more. Deployment analytics and insights help improve the overall customer experience.
- Improving deployment hit-rates and reducing the risk of security breaches or CRA non-compliance fees with real-time device inventory to support software bill of materials (SBOM) and CVE management.
Instead of replacing the existing homegrown system entirely, an augmentation approach can alleviate current system challenges while reducing operational risk. Companies should consider buying a complementary solution that can quickly fill gaps. An augmentation approach can also be a viable way to transition systems and progress towards a future-proofed infrastructure.
Summary
When deciding on critical product infrastructure, such as the software update system, organizations should conduct a thorough, data-driven analysis. Whether building an in-house system, purchasing a third-party solution, or undertaking an augmentation approach, there are various benefits and risks for each. The total cost calculations, core competency (competitive differentiation), and business value are among the most important aspects of the analysis.
Regardless of the path chosen, the business value of the software update system must be defined. Without holistically understanding the tangible value the software update system provides across stakeholders, any system will face challenges in the future and, in the worst case, be rendered irrelevant to the business.
Appendix A: Examples of the typical benefits and risks for buying versus building a software update system
With the list of benefits and risks at hand, one should go into further detail and evaluate the validity of each item for the organization and its potential options.
For example, the first benefit of building a solution is “Full control over features and roadmap.” To test the validity of this benefit, the organization should evaluate the extent to which it can actually impact the features and roadmap of the potential solution vendor(s). All statements should be questioned and scrutinized. It might not be true that buying a solution leads to limited customization, for instance, or that building a system enables deeper integrations.
|
Benefits |
|
|
Building a solution |
Buy a solution |
|
Full control over features and roadmap |
Faster deployment and time-to-value |
|
Deep integration with existing systems |
Proven solution with customer and regulatory compliance validation |
|
No vendor lock-in |
Vendor handles maintenance and security |
|
Can become a competitive differentiator |
High quality of service |
|
Long-term cost efficiency if core to business |
Access to vendor expertise and support |
|
Risks |
|
|
Building a solution |
Buying a solution |
|
High upfront investment |
Limited customization |
|
Ongoing maintenance burden |
Vendor lock-in and switching costs |
|
Slower time-to-market |
Recurring fees compound over time |
|
Diverts engineering from the core product |
Dependency on the vendor roadmap and stability |
|
Risk of underestimating complexity |
Potential integration complexity |
Appendix B: Summary table of weighted scores
Once the topics most relevant to the company are determined, the next step is to assign a value to each.
For example, if “Roadmap control” is relevant, it should be scored. “Roadmap control” is considered somewhat important to the organization, so it receives an importance score of 5. Then, score the two options according to how well they facilitate or constrain the topic. In this example, “Building a solution” results in a score of 10 as it retains total control, and “Buying a solution” results in 4 as there is limited roadmap influence with the chosen vendor.
|
Topic |
Importance |
Build |
Buy |
|
Roadmap control |
5 |
10 |
4 |
|
Integrations with other processes |
7 |
7 |
5 |
|
Vendor lock-in |
7 |
10 |
3 |
|
Time to market |
10 |
3 |
8 |
|
Regulatory Compliance |
10 |
3 |
9 |
|
Maintenance burden |
7 |
10 |
4 |
|
Costs (labor vs. recurring license) |
10 |
2 |
9 |
|
Future-proofed |
5 |
7 |
10 |
|
Allow us to focus on core competence |
7 |
2 |
9 |
|
Quality of service (deployment errors) |
10 |
5 |
7 |
|
System resiliency (reduced bus-factor) |
5 |
2 |
10 |
Doing this exercise provides a holistic score for both options. It can also be applied to multiple options, such as multiple vendors or multiple internal build plans.
Graphing the scores provides a quick visualization that highlights the benefits and risks to the enterprise. This can be used for further discussion and refinement.
As with any strategic decision, analysis is critical. Scores and importance will vary by individual, so the perspective needs to be considered or weighted (i.e., averaged). To get the most accurate options, one should also engage with vendors and seek to come as close to the truth as possible. Assumptions will skew the results.
Appendix C: Example model for determining the a business valueTitle
|
OTA Business Value Model - input values |
||
|
Example: 50,000 device fleet, industrial IoT |
||
|
Parameter |
Value |
Notes |
|
Fleet & Deployment |
||
|
Number of devices in fleet |
50,000 |
|
|
Deployments per device per year |
12 |
|
|
Total deployments per year |
600,000 |
|
|
Current deployment error rate |
8.0% |
Homegrown baseline |
|
Target deployment error rate (vendor) |
0.5% |
Vendor SLA |
|
Cost Parameters |
||
|
Avg. cost per truck roll (unscheduled field service) |
500 |
€ |
|
Avg. cost per bricked device (replacement) |
1,200 |
€ |
|
Avg. cost per support call |
35 |
€ |
|
Brick rate (% of failed deployments) |
2.0% |
|
|
Support call rate (% of failed deployments) |
25.0% |
|
|
Fully loaded cost per OTA engineer (annual) |
150,000 |
€ incl. overhead |
|
Number of OTA engineers (homegrown) |
3 |
|
|
SRE allocation to OTA (%) |
20.0% |
1 of 5 services |
|
Fully loaded SRE cost (annual) |
140,000 |
€ |
|
Cloud hosting cost for OTA (annual) |
60,000 |
€ compute+storage+traffic |
|
Vendor license cost (annual) |
120,000 |
€ SaaS subscription |
|
Integration/migration cost (one-time) |
80,000 |
€ estimated |
|
Total Cost of Ownership — Build vs. Buy (3-Year) |
|||
|
Year 1 |
Year 2 |
Year 3 |
|
|
BUILD (Homegrown) |
|||
|
Engineering team (3 engineers) |
€450,000 |
€450,000 |
€450,000 |
|
SRE allocation (20% of 1 FTE) |
€28,000 |
€28,000 |
€28,000 |
|
Cloud hosting (OTA infra) |
€60,000 |
€66,000 |
€72,600 |
|
Truck rolls (failed deployments) |
€2,400,000 |
€2,400,000 |
€2,400,000 |
|
Bricked devices |
€1,152,000 |
€1,152,000 |
€1,152,000 |
|
Support calls (deployment issues) |
€420,000 |
€420,000 |
€420,000 |
|
TOTAL BUILD COST |
€4,510,000 |
€4,516,000 |
€4,522,600 |
|
BUY (Vendor Solution) |
|||
|
Vendor license (annual SaaS) |
€120,000 |
€120,000 |
€120,000 |
|
Integration/migration (one-time) |
€80,000 |
€0 |
€0 |
|
Remaining internal effort (1 engineer, integration) |
€150,000 |
€75,000 |
€75,000 |
|
Deployment error costs (reduced) |
€248,250 |
€248,250 |
€248,250 |
|
TOTAL BUY COST |
€598,250 |
€443,250 |
€443,250 |
|
ANNUAL SAVINGS (Build - Buy) |
€3,911,750 |
€4,072,750 |
€4,079,350 |
|
CUMULATIVE 3-YEAR SAVINGS |
€12,063,850 |
||
|
Engineers freed up for core product work |
2-2.5 FTEs |
||
|
Note: All assumptions in blue are editable on the Assumptions tab. |
|||
Appendix D: Common reasons to buy a solution
Below are typical reasons for buying a software update solution.
- Focus on core business
- Software update systems are infrastructure. The company wants to dedicate engineering to product differentiators, not commodities. Developer and operational efficiency tools such as CI/CD, IDEs, software update solutions, etc., are rarely business differentiators.
- Faster time to market
- Avoid 12-18+ month build cycles; deploy proven solutions immediately.
- Enhancing existing solutions to meet new regulatory requirements (like CRA) will be time-consuming and an ongoing effort.
- Lower total cost of ownership
- Building requires ongoing labor, SRE overhead, infrastructure costs, compliance tooling, and continuous regulatory updates—often exceeding vendor fees
- Leverage proven technology
- Vendors have invested millions over the years; inherit battle-tested security, scalability, and feature maturity. Homegrown systems often lack deployment statistics, inventory insights, audit logs, etc., which are critical to success
- Reduce operational risk
- Eliminate employee lock-in (bus factor); vendors provide dedicated support, SLAs, and continuous improvement
- Meet compliance demands
- Regulations like CRA require audit logs, SBOM reporting, and security by design—expensive to retrofit into homegrown systems
- Competitive parity
- Industry leaders already use commercial OTA; building diverts resources while competitors ship faster
The economics of software update systems: Measuring the total cost of ownership for building and buying solutions
Securing remote diagnostics: Safe, reliable software updates for medical imaging hardware
