Almost every hardware team starts in a wiki and a folder of spreadsheets. Not because nobody thought about it, but because that stack is genuinely good at the first thing you need (writing things down where others can read them) and free at the point of use.
It stops working at a predictable point, and it is worth being precise about where, because "use a real tool" is not an argument that survives contact with a team that has 200 Confluence pages and no budget.
What wikis are actually good at
Give credit first. A wiki is the right tool for:
- Decisions and rationale. Why we chose a solid motor over a hybrid. Why the avionics bay moved forward. Prose is the correct format for reasoning, and a wiki page dated and attributed is a genuinely good record.
- Procedures. How to run a static fire. How to prep the recovery system. A checklist that changes twice a year lives happily on a wiki page.
- Onboarding. New members need narrative, not a database. "Here is how this team works" is a page, not a table.
- Meeting minutes and long-form context. Anything whose value is in the sentences rather than the values inside them.
If you take nothing else from this: do not migrate your rationale pages. They are fine where they are, and a team that tries to move everything at once usually gives up and moves nothing.
The three things that break
1. A wiki page is a snapshot, not a value
The moment a page contains a number that also exists somewhere else, the wiki is being used as a database and it has none of the machinery for that job. It does not know that the mass on this page is the same mass as on that page. It will let them disagree indefinitely and never say a word.
This is parameter drift, and a wiki is a very efficient way to manufacture it, because pages are cheap to create and impossible to audit. Every page is written by someone who had the right number that day.
The tell is a page with a "last updated" of eight months ago containing a number you are about to design against. There is no way to know from the page whether it is current, and the person who wrote it has graduated.
Notion databases are the closest thing to a fix inside the wiki world, and they do genuinely help. You can put parameters in a table with typed properties and relate rows to each other. Where it falls down is that a Notion relation is a link, not a dependency: nothing recomputes, nothing gets flagged, and there is no notion of a version that other work was built against. You have made the data tidier without making it safer.
2. Nothing knows what depends on what
Change a requirement in Confluence and precisely nothing happens. No page turns a different colour. Nobody is notified. The six pages that were written against the old requirement continue to look authoritative.
For a software team this is survivable, because the code is the source of truth and CI tells you when something breaks. Hardware has no equivalent. The document is the artefact. If the document does not know its own dependents, nothing does.
This is the single biggest gap, and it is not fixable with better wiki hygiene. It is a data model problem. Pages link to each other as prose, not as dependencies, so "what breaks if I change this" is a question the tool structurally cannot answer. You can approximate it with a naming convention and a lot of discipline, and teams do, and it degrades the moment someone is busy.
3. A component is not a page
The thing a hardware team most needs to track is a physical object with a lifecycle: designed, ordered, arrived, tested, qualified, integrated, flown, retired. It has a serial number. It has an operating envelope it was actually qualified for. It has a history of what it has been through, and how much life it has left.
A wiki page cannot represent any of that in a way you can query. You cannot ask a wiki "which pressure sensors are qualified above 40 bar", or "which components on this vehicle have never been tested", or "what is still bound to v2 of the propulsion spec". Those are the questions that matter in the four weeks before a launch, and in a wiki all of them are answered by a person reading pages and remembering things.
Where spreadsheets fit and where they don't
Spreadsheets are better than wikis for values, and worse for everything else. A mass budget in a spreadsheet is genuinely good: the arithmetic is right there, and it recalculates. For a single-owner numerical model that one person maintains, a spreadsheet is often the correct answer and adopting anything heavier is a mistake.
Three things kill them at team scale.
Concurrency. One file, one editor, and the instant two sub-teams need to move at once, somebody takes a local copy. That copy is a fork of your source of truth, and it will be reconciled by hand, badly, or not at all. Cloud spreadsheets solve the file-locking version of this and not the underlying one: simultaneous editing is fine, but two people making incompatible assumptions in different tabs is still invisible.
No concept of a component. A row is a row. A spreadsheet cannot enforce that a part in the "qualified" column has an actual test record behind it, so the column becomes a statement of intent rather than of fact. The word "qualified" in a spreadsheet cell is worth exactly as much as the memory of whoever typed it. See flight-proven is not qualified for how that specifically goes wrong.
No history you can use. Version history in a cloud spreadsheet tells you that a cell changed. It does not tell you why, who agreed, or what else was built against the old value. So a spreadsheet can tell you the past existed without letting you reason about it.
What about PLM, or Jira, or a requirements tool?
Worth addressing, because the obvious answer to "wikis are not built for this" is "then buy the thing that is".
Traditional PLM genuinely solves configuration management. It is also priced and scoped for organisations with a dedicated configuration manager, implementation timelines measured in quarters, and a change-control process that assumes a full-time person administering it. For a twenty-person student team with a launch in March, the tool will not be the bottleneck, the process around it will.
Jira and issue trackers are good at work and bad at state. They track that someone should update the mass budget. They do not hold the mass. A task closes and the knowledge in it evaporates, which is why teams end up with a tracker full of closed tickets and no answer to what the current configuration is.
Requirements tools cover requirements well and stop at the boundary of the physical thing. You get traceability from requirement to verification, and then the component, its qualification envelope, and its accumulated life live somewhere else entirely.
None of these are bad tools. They are shaped for organisations that are not you, and the cost of that mismatch is usually paid in process overhead rather than licence fees.
The honest comparison
| Wiki | Spreadsheets | PLM | Purpose-built | |
|---|---|---|---|---|
| Decisions and rationale | Good | Poor | Adequate | Adequate |
| Numbers with one definition | Poor | Adequate | Good | Good |
| Knowing what depends on what | None | None | Good | Good |
| Component lifecycle | None | Poor | Good | Good |
| Concurrent editing | Good | Poor | Adequate | Good |
| Setup cost | None | None | High | Low |
| Cost at a student budget | Free | Free | No | Depends |
| Survives annual handover | Poor | Poor | Good | Good |
The last row is the one student teams underrate, and it is the one that compounds. A generic-tool stack degrades every year, because its integrity depends entirely on institutional memory, and institutional memory graduates. Every August you inherit documents nobody can vouch for, and the safest assumption is that all of it is stale. So people rebuild from scratch, and the team relearns the same lessons on a four-year loop.
That loop is the actual cost. Not the hours lost to a wrong number once, but the fact that your team's competence resets every time a cohort leaves.
What to do about it
You do not need to move everything, and the teams that try usually stall.
- Leave rationale and procedures in the wiki. They work there. Moving them buys nothing and costs a weekend.
- Move parameters out of prose. Anything that is a value with more than one consumer needs one definition and references to it, not a transcription into every document that needs it.
- Move components out of spreadsheets. A part with a lifecycle and a qualification envelope needs a record that can enforce its own rules.
- Do one sub-system first. Mass budget, usually, because it is where drift has most recently embarrassed everyone. Finish it before starting another.
- Leave a pointer behind. When a parameter moves, replace it in the old page with a link rather than deleting it. Half-migrations fail when people cannot find where things went.
The goal is not tool consolidation for its own sake. Consolidating tools is a tidiness project and tidiness projects lose to launch dates. The goal is that a change in one place announces itself to everything downstream, which is the one thing the wiki-plus-spreadsheet stack cannot do at any level of discipline.
If your team has never been bitten by this, keep the wiki. Genuinely. The argument for changing anything only starts once you have lost a fortnight to a number that was wrong in a place nobody thought to look.
Prototype is a purpose-built version of the right-hand column, built inside a university rocketry team for teams on student budgets. See the comparison, or read about parameter drift, which is the failure mode all of this is organised around.