# The Adoption Crisis Category: Case Study Published: October 2026 Read time: 16 min read URL: /resources/adoption-crisis Bullish on hardware while bearish on software, has become the new trend. This read highlights one of the hidden elements that will dictate the exponential of this trend, yet it's right adoption seems to be in a crisis. --- Industry Analysis # The Adoption Crisis Bullish on hardware while bearish on software, has become the new trend. This read highlights one of the hidden elements that will dictate the exponential of this trend, yet it's right adoption seems to be in a crisis Most hardtech companies do not lose their grip on their programmes in a crisis. They lose it quietly, in the first few years, when ensuring it would have cost almost nothing but nobody cared enough. The bill arrives later: in integration tests that fail for reasons too tangled to trace, in change reviews that bleed time in meetings, and in decisions where managers become clueless, struggling to find the right answers. This article draws on our conversations with founders, engineers, and programme managers across hard-tech companies over the past months. Certain patterns keep emerging based on who is where, and at what time. Most of those decisions look rational considering their present and the past. But it is the future we are worried about, and this article explains why. ## The hidden layer Systems engineering is one of the most crucial layers in complex hardware engineering, yet one of the most underestimated. It involves designing architectures, making sure intent is understood across, and aligning teams to ship what technically needs to be. Metaphorically, in a society, this is the policy authors and its enforcers, which essentially means shaping the society. In a company it is often one department, a handful of people, and a set of tools they have been given to play with. That is it. When things start failing, individuals can be blamed. Processes can be reformed. Tools can be changed, right? Well, not exactly — **tools persist**. Slowly they become the bottleneck. The same failures keep recurring and start hitting the business hard while the tools stick around. But why? To understand this phenomenon, let's walk through the phases of a typical hard-tech company. Stage one ## Early stage, when everything works In the early stage, systems engineering is not a problem, and it is important to say so plainly. A team of ten sits close together. Everyone knows who changed what. The founders review every significant design change. A spreadsheet of requirements, a Jira board, Lucid diagrams, and a GitHub repository are enough, because the real system model lives in a handful of heads that collaborate with each other every day. Few rare startups that start on with a legacy PLM such as Teamcenter, or MBSE tools like CATIA Magic are also happy. The reason is that the tool is used mainly as a document store, a cabinet meant to be filled. Nobody is yet relying on it for a root cause analysis, since its easier and faster with manual syncs, or perform impact analysis across dozens of interconnected teams. The priorities are correct for the stage: prove the technology, build prototypes quickly, win the next round or the first customer. Scalability is rarely discussed. Things are assumed to be replicated downstream. The reasons behind a tolerance, a material choice, a waived requirement, or a test that was skipped are discussed in a meeting or a chat thread and never attached to the artefact they explain. At this stage that costs nothing, because the people who know are still in the room. **What stage one quietly accumulates is the context debt** which looks free until the people who hold it leave the room. Manual linkages until the permutation starts coming into play. Stage two ## Growth, when the cracks appear Growth is where the debt from stage one starts to be collected. The team grows past the point where everyone can attend the same meeting. Sub-teams form around subsystems. Suppliers, contract manufacturers, and customers begin to depend on engineering data. The founders can no longer review every change. The symptoms are familiar to anyone who has lived through them. Meetings multiply because they are the only reliable way to find out what changed. A change to one part triggers a chain of questions nobody can answer quickly: which requirements does it touch, which tests must be repeated, which supplier drawings are now stale, which data proves what. Engineers spend a growing share of their week on coordination rather than engineering. Companies respond in one of three ways. Response | What it looks like | What it costs | How it plays out Hire people as the connecting dots | Managers and engineers become human middleware. | Headcount, which feels cheaper than a tool and easier to adjust. | Knowledge and context vanish when people are absent or leave. High manual dependency. No observability. Internal hacks and stitched tools | Vibe-coding, scripts, and shared dashboards on top of whatever is already in use. | A dedicated team at minimum: a systems engineer for the vision, an AI specialist, and a software engineer plus constant maintenance. | Links break when any tool, field, or convention changes. Nobody owns the glue. It becomes another internal system, another silo, struggling to solve for the underlying issues. Buy a dedicated legacy PLM | Licences for an established suite, and new workflows that exist to feed it. | Migration of engineering data, training, and the time to make the tool look adopted. | The tool is used for storage. Traceability exists on paper for auditors and stops being useful for engineers. No impact analysis. No observability. nothing At this stage the decision is often made so quickly, that it's cascading impacts is not thought through. A leader hears a familiar name, and accepts it as the way forward. Sometimes prior experience brings in a familiar tool, or the old way of doing things is inherited as-is. The pressure to deliver forces decison makers to reduce risk by accepting the convential ways. For many companies, especially in regulated industries, the deciding reason to buy a legacy systems engineering tool is not engineering at all. It is the audit. Certifiers, notified bodies, and customer quality teams want controlled records, signed approvals, and an audit trail they recognise, and an established, validated PLM provides exactly that. It is a sound reason to buy one. What it does not provide is the live, on the go traceability that is supposed to be there. That still has to be stitched together manually by engineers. The three responses merge towards a common pattern. **None of them reliably preserves the reasonings and the relationships between artefacts, or the reasons behind decisions.** Humans are still directly or indirectly connecting the dots that keep multiplying, bits and pieces of the system model remains in heads. Those were precisely what had started accumulating from stage one. Stage three ## Scale, when it's too late At scale, organiszations have adapted to a legacy PLM that is embedded in it's daily work. Hundreds of engineers release parts through it, suppliers receive data from it, and quality and compliance processes depend on it. On paper, the problem from stage two has been solved. In practice, the engineers and managers we speak to describe the same frustrations, only larger. Delays nobody can explain early A slip becomes visible when a milestone is missed, not when the dependency that caused it changed weeks earlier. No observability Directors and programme leads cannot see the state of the system without asking people to assemble it, so status reporting becomes a job in itself. Manual synchronisation Requirements, CAD, software, test results, and supplier data each live in their own system. People reconcile them by hand, in meetings and spreadsheets. Slow root-cause analysis When a test fails or a field issue appears, reconstructing which change caused it, who approved it, and why can take days or weeks. Teams respond by building tools for their own corner: a test-results dashboard here, a requirements exporter there, a change-impact script in one subsystem team. Each tool helps the team that built it. Together they create more silos, and leadership still has no shared view. Replacing the PLM is rarely a realistic option by this point. Years of data, integrations, validated processes, and trained habits sit inside it. In regulated industries, the validation effort alone can be prohibitive. **Now their legacy tooling stack is a spouse who will not grant a divorce even when you want one.** The trap ## Everyone is drifting in the same current Each stage above is a reasonable response to the moment, and that is what makes the trap so hard to see. No single decision is wrong. The cost arrives years later, spread thinly across missed milestones, slow root-cause analysis and engineers working as human middleware. And because almost every hardtech company is drifting in the same current, the drift feels like normal sailing. When your peers lose the same weeks to the same meetings, the loss stops registering as a loss. It becomes the cost of doing business, and nobody thinks to steer against it. Over decades, the current has also shaped what the industry believes is possible. Programme timelines are set by experienced people, and their sense of how long things take is built from the programmes they have lived through. A vehicle takes this long, a certification takes that long, an integration phase always overruns by a few months. Those averages already include the meetings, the manual reconciliation and the weeks spent tracing a failure back to its cause. Because we plan around the drift, we no longer see it. Software has just shown how quickly that kind of assumption can break. A few years ago, nobody would have predicted that a working prototype could go from idea to deployment in an afternoon. Vibecoding removed the friction between intent and execution, and the industry's sense of "how long things take" reset almost overnight. Hardware cannot escape physics. Parts still have to be machined, tested and certified. But a large share of a hardware programme's time is not spent on physics at all. It is spent finding information, reconciling it and waiting for someone who knows. That share is where hardware engineering's own reset is waiting to happen. A few have already started steering against the current. SpaceX did not accept the industry's standard stack. Several engineers who worked are now trying to bring that way of working to the rest of the industry. VinciStack comes from the same conviction. We have worn the hats of the engineers who live with these problems every day. We are therefore on the mission to rescue them all and change the way hardware engineering has been assumed to be done. > The fastest hard tech companies of next generation would be the ones who have the audacity to look beyond conventional fragmented, lethargic ways. The record ## History repeats itself The most useful evidence comes from formal accident and inquiry reports, because they reconstruct decisions in a level of detail that companies rarely publish. The four cases below are well documented. In each, the information needed to prevent the failure existed somewhere in the organisation, but it was not connected to the decision that needed it. We use these cases with care. Two of them involved the loss of spacecraft; one involved the loss of 346 lives. We do not claim that any single tool would have prevented them. We cite them because their inquiry boards describe, in plain language, the same mechanisms that cause smaller and less visible failures in hard-tech companies every week. Case | What was lost | Mechanism Airbus A380 wiring | More than two years of schedule and several billion euros | Sites used incompatible design tools, so wiring changes could not be integrated into a single model. Boeing 737 MAX MCAS | Two aircraft and 346 lives; worldwide grounding | A function changed during development, but the safety documents describing it were not updated, and its description was fragmented. Mars Climate Orbiter | The spacecraft | Two teams worked to the same interface specification but used different units. Ariane 5 Flight 501 | The maiden launch vehicle | A design rationale and a reused requirement were never re-examined against the new vehicle. > Information propagation is the core problem of systems engineering. What matters is knowing, at the moment of change, which other artefacts and decisions are effected. What needs to done. Patterns ## What we come across Every hardtech company has its reasons for working the way it does. After months of conversations with founders, engineers, programme managers and quality leads, we found that most companies share the similar pattern of feedbacks. They are good reasons. That is the problem. Each one makes sense on the day it is said and costs more every year after. Here we present you what we heard, why it holds up, and what we have learned since then . We don't have the bandwidth to adopt a new tool now. Rolling out would derail us. Why it holds A team that is behind schedule cannot absorb a migration, retraining, or a new workflow. Rollouts take longer and cost more than planned. Personal and team milestones are real, and a rollout is costly to the person who sponsored it. How we see it This is a sincere one, so our adoption model is designed around it. VinciStack does not require data migration, because it starts pulling in from existing tools. It does not require engineers to change how they work on day one, and it is not an organisation-wide rollout. We start with one programme or subsystem and one question that is currently painful — such as “what is affected if we change this?” or “why did this test start failing?”. If that question is not answered faster then your usual ways, our value proposition has failed on your terms. Expansion follows evidence, programme by programme. The bandwidth argument also cuts the other way. The meetings and manual reconciliation that consume a team's week are themselves the bandwidth problem.