Hardware Engineer Still Running on Excel, Google Drive and Notion? Here Is Why It Does Not Scale

These tools are excellent. The problem is not what they do. The problem is what happens between them.

Look at the software stack of a hardware team of 50 to 300 engineers. It is almost always the same. A CAD tool for geometry. Excel for the BOM, mass budgets, requirement matrices. Google Drive for test reports, design review minutes, design files. Notion or Confluence for coordination. Email for decisions. Sometimes a requirements tool, sometimes the beginning of a PLM.

Each of these tools is deep in its own task. CAD models geometry better than anything else. Excel computes fast. Drive stores everything. Notion documents cleanly. Taken in isolation, none of them is a bad choice.

The problem is structural: the truth of a complex physical system does not live in any of these tools. It lives in the relations between the data they hold. Which requirement drove which architecture choice. Which component carries which function. Which revision was tested, by whom, with what result, and on exactly which configuration. And it is precisely at the boundaries between tools that this information leaks away.

Vertical tools, orphaned data

A vertical tool is built around one task: drawing, computing, writing, planning. It optimizes that task and stops there. The CAD file knows nothing about the requirement. The BOM spreadsheet knows nothing about the test report. The Notion page knows about neither. Each tool holds a partial copy of the system, expressed in its own format, frozen at its own date.

At every boundary, a human copies data across. They export a mass from CAD, paste it into the roll-up spreadsheet, report the total on the project page, write it into the review file. Four copies of the same quantity. No link between them. The day the CAD changes, three copies become wrong and nothing flags it.

This is what data leakage between vertical tools means. Not lost files. Lost consistency. The files are all there, neatly organized in Drive. What has disappeared is the guarantee that they say the same thing at the same time.

First flaw: nothing centralizes

A well-organized Drive folder gives an impression of centralization. It is an illusion. Drive centralizes storage, not data. A test report PDF is an opaque object: the measured value inside it does not exist for any system, it exists only for the human eye that will open the document. It cannot be queried, compared, fed into a computation, or checked against the right revision of the component.

A single source of truth is not a place where everything is filed. It is a place where every quantity in the system exists exactly once, in structured form, and where everything else references it instead of copying it. Excel, Drive and Notion cannot offer that: their base unit is the file or the page, never the engineering object.

Second flaw: individualistic models

Open three BOM spreadsheets in the same company. You will find three different structures. Different columns, different naming conventions, roll-up formulas rewritten three times, with three interpretations of the edge cases. Each spreadsheet is its author's mental model, frozen into cells.

These individual models have two consequences. The first is error: a literature review published in 2024 in Frontiers of Computer Science concludes that 94% of spreadsheets used for business decisions contain errors, largely because their authors build complex logic without any of the quality practices of software development. A multi-level BOM with recursive mass, cost and power roll-ups is exactly that kind of complex logic.

The second consequence is dependence on individuals. The spreadsheet does not survive its author. When they leave, the team inherits an artifact nobody dares to touch. Knowledge of the system has become tribal: it lives in a few heads, not in a shared structure that anyone can read, verify and extend.

Third flaw: coordination depends on manual updates

In an Excel, Drive, Notion stack, there is no propagation mechanism. A design change updates neither the BOM, nor the requirement matrix, nor the project page, nor the review file. Every ripple is a manual act, performed by someone who must first know the change happened, then remember every place it propagates to.

Engineers become the synchronization layer of the information system. Recent analyses of engineering data management estimate that around 25% of team time goes into these zero-value tasks: finding files, reconciling contradictory versions, rebuilding lost context. One full day per week per engineer, spent maintaining by hand a consistency the tooling should guarantee.

With 10 engineers, this holds. The product is still simple, everyone knows everything, copies barely diverge. With 100 engineers, product variants, customer configurations and subcontractors, the number of boundaries grows faster than headcount. Every new team, every new spreadsheet, every new variant adds copies to keep in sync. That is the exact definition of something that does not scale: the coordination cost grows faster than the organization's capacity to absorb it. The Hexagon survey published in 2026 confirms it at industry level: 98% of manufacturers report data problems that directly slow down innovation and time-to-market.

The audit, when the bill arrives

As long as the product moves forward, fragmentation remains a diffuse cost. The audit makes it visible all at once. ISO 13485, AS9100, 21 CFR 820, nuclear safety cases: all these frameworks ask the same question in different forms. Show the chain. From requirement to design, from design to test, from test to delivered configuration, with the decisions and the owners at every link.

When data lives in files, answering that question is a project in itself. FDA inspection data for fiscal years 2022 to 2024 consistently ranks CAPA and design controls at the top of Form 483 observations: requirement management, verification, validation, document control. In other words, what inspectors sanction most often is not the quality of the engineering itself, but the inability to produce structured evidence of it.

Teams that prepare an audit on a stack of files know it: preparation takes weeks, produces disposable summary spreadsheets, and depends entirely on the availability of the people who hold the history. The result is fragile. The auditor's next question can force you to rebuild everything.

What is needed instead

The answer is not to replace CAD, nor to ban Excel. Task-specific tools stay. What is missing is a layer underneath: a structure where the engineering objects of the system exist exactly once, with their relations made explicit.

Concretely, this layer does four things. It models: requirements, functions, components, interfaces, tests and decisions are typed objects, linked to each other, not spreadsheet rows. It computes: mass, cost or power roll-ups are computed attributes on the product graph, deterministic, recalculated on every change, identical for everyone. It locks: a baseline is a frozen, versioned state of the system, not a dated folder in Drive; you know exactly what was frozen, when, and what has changed since. It traces: every object carries its history, every link is navigable in both directions, and the answer to an auditor is a query, not an investigation.

This is what we are building with Koddex: an Engineering Operating System for complex physical systems. Teams model their product, lock their baselines, manage their revisions and maintain end-to-end traceability. Vertical tools keep doing what they do well. The data stops leaking between them.

Excel, Drive and Notion carried your team this far. The question is not whether they are good tools. It is whether your engineering truth can keep living in unsynchronized copies while your product, your team and your regulatory obligations grow. The numbers above give the answer.

See what a single source of truth looks like on your own product. Explore the Engineering Operating System or book a demo.

Sources

- Poon P.-L. et al., "Spreadsheet quality assurance: a literature review", Frontiers of Computer Science, 2024. DOI 10.1007/s11704-023-2384-6.
- LatentView Analytics, "Engineering Data Management", 2026.
- Hexagon, industry survey cited in "Trends Reshaping PLM for 2026 and Beyond", HCLTech, 2026.
- FDA, public inspection observation database (Form 483), fiscal years 2022 to 2024, 21 CFR Part 820.