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.
A slip becomes visible when a milestone is missed, not when the dependency that caused it changed weeks earlier.
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.
Requirements, CAD, software, test results, and supplier data each live in their own system. People reconcile them by hand, in meetings and spreadsheets.
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.
We already have a legacy MBSE or PLM tool. Can't move off them, so no point.
Why it holds
The company has paid for the tool, migrated data into it, and trained people on it. Being told it needs something else sounds like being told the investment was wasted. Replacing an embedded, validated PLM or MBSE stack can take years and can put certification at risk.
How we see it
It was not wasted, and we do not ask you to replace it. A PLM or MBSE tool can be good at what it was built for: managing parts, BOMs, revisions, models, and audit control. It was not built to bridge and build the context from one requirement tool to a firmware commit in another, a test result in a third, and a supplier change notice in an email.
The A380 programme had professional CAD and PLM tooling at every site. The failure lived between them. VinciStack orchestrates with the systems you are committed to, gives you the true observaibility and faster root cause analysis. Your PLM can keep the system of record for now as it is.
You first need a way for everyone in the household to understand each other - connect the dots.
We don't need this. We're working fine. Focused on proving the tech — process can wait.
Why it holds
With a small, co-located team and founders in every decision, spreadsheets and Jira are adequate. Adding process too early slows a team that needs speed above everything. A company that does not prove its technology does not survive to have a scaling problem.
How we see it
We agree that you do not need a heavy process. The question is whether you are recording the one thing that cannot be recovered later: why decisions were made. The cost of capturing intent while it is fresh is close to zero. The cost of reconstructing it after the people have moved on is unbounded.
Proving the technology involves a lot of rapid iteration, and rapid iteration is exactly when changes outrun memory. When a prototype test fails, the speed of your next iteration depends on how quickly you find which change caused it. That is a speed problem, not a governance problem.
An intelligence layer that captures context from the tools you already use, without asking engineers to fill in forms, is the lightest way to do that.
We'll build it ourselves, internally. With AI it is doable. Better process and a good systems engineer will fix this.
Why it holds
AI has made the first version of almost any internal tool fast to build. Engineers know their own process best, at first it is the most convienent thing any org will try to do.
How we see it
A tool that connects engineering context has to maintain integrations as APIs change, hold a data model of how artefacts relate, keep that model correct as the product and the team change, enforce access control, and make answers traceable to their sources. That is a product, with a roadmap and those people are usually pulled from the core product.
There is also an irony we see repeatedly: the internal tool's own design intent lives in the heads of the two or three people who built it. When they leave, the tool becomes the next undocumented system. We agree that systems engineers are essential, and we build for them. But the Mars Climate Orbiter team had a systems engineering function and a formal anomaly process. The board found the function was not robust enough, and the process was bypassed under pressure. A good systems engineer with a connected view of every artefact will catch far more than the same engineer working from spreadsheets and meeting notes.
The intelligence layer
What changes when relationships, not just artefacts, have a system of record
Hardware engineers have built some of the most remarkable machines in history while holding a torch over their own corner. For decades, a system has just been a collection of its artefacts: the requirements document, the CAD model, the firmware repository, the test report, telemetry, the diagrams. Each one is carefully controlled in its own tool. But a machine is not just the sum of its artefacts. It includes the web of relationships between them: which requirement a part satisfies, which test proves it, which decision shaped it and which change put it at risk. That web has never been visible concretely. It has lived in a few experienced minds, and it has moved at the speed of their calendars.
An intelligence layer builds and makes that web visible. It reads everything a programme produces, understands how the pieces relate, and keeps that understanding current as the work moves. The relationships are as visible as the artefacts themselves. The system stops being a collection of files and becomes something a whole team can see, question and reason about at once
Imagine changing a component and seeing, before anything is commited, every requirement, test, supplier and team it will touch. Imagine a test failing at midnight and its cause traced back, before the morning stand-up, to a decision made months earlier and several teams away. Imagine asking "why was this tolerance chosen?" and receiving the reasoning and the evidence behind it, years after the engineer who chose it has moved on. A new engineer could understand on their first day what used to take years on a programme. Certification evidence would never be assembled in a scramble, because the traceability would have been building itself since day one. And programme leaders would see a delay forming the moment a dependency shifts, not weeks later when a milestone is missed.
This layer becomes the orchestrator of engineering. Every tool keeps doing what it does best, but the layer is where the whole system comes together: where changes are weighed, risks surface, decisions are recorded and products are readied to ship. It is the place a team goes to understand the machine they are building, rather than the cabinet they go to find a file.
None of this asks engineers to work differently. It asks only that the knowledge they already create stops being scattered and starts being connected. When that happens, the limit on how fast hardware can move is no longer the time spent finding, reconciling and waiting. It is physics, and ambition.
Each tool a hard-tech company uses is a system of record for one kind of artefact. None of them is a system of record for the relationships between artefacts, or for the reasons behind decisions. That is the gap every case in this article fell into, and it is the gap VinciStack is built to close.
Closing
Local optima don't carry you far. The global optimum is what wins.
Every company in this article seems to be making a sensible choice, given where they are. Early teams spend their energy proving the technology rather than caring about scalability. Growing teams follow what has been the conventional way. Scaled companies are right not to tear out a PLM their certification depends on. Each decision is the best answer to the question in front of it. The trouble is that a series of locally optimal decisions does not add up to a globally optimal functioning system. Each choice protects the next quarter, and each one quietly adds to a cost that keeps piling, and hits so hard later.
Many consider our kind of solution a “good to have” rather than a “must-have”, kind of same way how many Indians saw protein supplements as a luxury for athletes, not a part of everyday health. It took the pandemic, and a new awareness of what neglect really costs, for that belief to change.
Our aim with this article is to let people look out for the global optimum, in order to have a better future. “Must-have” is a psychological phenomenon that only a few have been able to accept so far. We hope that this trend will increase, and that the hardware renaissance will be faster even than the software one.
The cost of fragmented engineering knowledge is already on your balance sheet. It is just filed under delays.