Every August, a university engineering team loses a third of the people who know how it works.
They graduate. The knowledge goes with them: which parts were actually tested, why the avionics bay moved forward, what the mass budget was really based on. What stays behind is a Drive folder nobody can vouch for and a wiki whose last editor left two years ago. The new cohort reads it, cannot tell what is current, and quietly rebuilds from scratch.
That is the loop Prototype was built to break. It came out of a rocketry team at UNSW, and it was not planned as a product. It was the thing we needed after the third time someone designed against a number that had changed months earlier.
Why a new tool at all
The honest answer is that we tried the alternatives first, for years.
Wikis are good at rationale and bad at values. A page is a snapshot of what someone believed the day they wrote it, and it has no idea that the number in paragraph three also lives on four other pages. Spreadsheets are better at numbers and worse at everything else: one editor at a time, no notion of what a component is, and a "Qualified" column that means whatever the person who typed it remembers.
Neither can answer the question that actually matters, which is "what breaks if I change this". That is not a discipline problem, and it is not solved by tidier documents. It is a data model problem. If a document does not know its own dependents, nothing does.
We also looked at the tools built for this. Configuration management is a solved problem in aerospace, and the solutions are priced and scoped for organisations with a full-time configuration manager and an implementation timeline measured in quarters. That is a completely reasonable trade for a company with a hundred engineers. It is not a trade a student team can make, and the result is that the teams with the highest turnover and the least institutional memory are the ones running on the least structure.
So the whole product is built around three failure modes, and it is worth being concrete about them because they are the only reason to adopt anything new:
- Parameter drift, where the same value disagrees in five places because it was transcribed into five documents that do not know about each other.
- Stale work, where a component was built against a parent spec that has since changed and nobody re-checked it.
- Unqualified reuse, where a flight-proven part gets used outside the envelope it was actually qualified for.
Everything in the product either serves one of those three or is a distraction. That test has killed more feature ideas than any roadmap discussion.
Where we are now
Further along than we expected, and earlier than the marketing site can help sounding.
Specifications with real versioning. A parameter is defined once and referenced rather than copied. Publish a new version and everything bound to the old one is flagged for review rather than silently carrying on.
Components with a lifecycle and a qualification envelope. A part moves from planned through to integrated, carries the bounds it was actually tested to, and flags itself when a spec it depends on moves.
Approvals that route themselves. Publishes and qualifications go through signoff groups, and the workflow chases pending reviewers so a lead does not spend their evenings doing it by hand.
Documents with revision history and full text search, including inside PDFs, because a team's real archive is mostly PDFs nobody can find twice.
Then the integrations, which matter more than we thought they would. Import an OpenRocket design and the airframe arrives as versioned components instead of being transcribed by hand. Link a GitHub repository and firmware can point at the hardware it runs on, so "does the software know about this change yet" has an answer instead of a meeting. Meetings are records rather than notes in somebody's laptop, with transcription and summaries that run on hardware you control.
That last one is worth dwelling on, because it changed how we think about the rest. Most of what a team knows never gets written down at all. It gets said out loud on a Tuesday and survives only in the memory of whoever was in the room. Capturing that is not a productivity feature, it is the same handover problem from a different angle.
What we got wrong
Worth saying, since a post that only lists wins is an advertisement.
We built the schema before we built the onboarding. The data model was right and completely impenetrable to a new member in their first week. Most of the last few months has been making a correct model approachable, which is slower and less satisfying than designing the model was.
We underestimated documents. We thought of them as attachments to the real records. In practice the document is the record for a lot of what a team does, and treating it as secondary meant revision history and search arrived much later than they should have.
We assumed teams would migrate everything. They do not, and they are right not to. The tool has to be useful when it holds one sub-system and the rest of the build is still in a spreadsheet, because that is the only realistic adoption path.
What is not done
Plenty.
Billing is wired up but plans are not chargeable yet, so pricing is indicative rather than final. There is no mobile app, and the web app on a phone is usable rather than good. The intelligence that is supposed to notice a problem before a human does is barely started. Offline is not handled at all, which matters more than we would like for teams who do test campaigns in places without reception.
And the tool is opinionated in ways that will annoy anyone whose process does not look like ours. We think a component should carry its qualification envelope. We think a parameter should have exactly one definition. Those are positions, not neutral defaults, and we will only find out where they are wrong by watching teams work around them.
We are also a very small team, which cuts both ways. Founding teams get a genuine say in what gets built, because there is nobody between them and the person writing the code. They also get the bugs first.
Where we are going
Four phases, in order. The first is done. The dates on the rest are targets, not promises, and if one slips we would rather move the date than ship the phase badly.
Foundations, live now. One place the whole build lives: specs, components, interfaces, approvals, documents, meetings.
Plugins and integrations, targeting Q3 2026. Works with the tools you already use rather than asking you to abandon them. The OpenRocket and GitHub work is the start of this, not the end. The principle is that a design tool stays the design tool, and Prototype holds the agreed configuration that comes out of it. Concretely, that means more import paths, a public API worth building against, and webhooks so a change here can drive something else. The failure mode to avoid is becoming a place people copy numbers into, which would just be a nicer spreadsheet.
Intelligence, targeting Q4 2026. Flags what looks wrong and suggests the fix. This is where the data model starts paying off. Once parameters are defined once and dependencies are real, "this component has never been tested above the pressure this mission needs" is a query rather than an argument. So is "these two sub-teams have been working against different versions of the same spec for three weeks". The goal is narrow and boring on purpose. We are not interested in a chat box that guesses. We are interested in the small number of checks that a human cannot run continuously and a machine can.
Agentic workflow, targeting Q2 2027. Agents that design inside your limits. The interesting part is not generation, it is the constraints. An agent that knows the qualification envelopes and the current spec versions can propose something that does not immediately violate them, and can show its working against records you can check. An agent without that context is a confident guess, which is the last thing a hardware team needs.
What we are not going to do
We are not going to become a general project management tool. There are good ones and we would lose.
We are not going to add a feature because one team asked loudly, if it makes the model less true for everyone else. The three failure modes are the filter, and we would rather say no and explain why.
We are not going to lock your data in. Export exists and will keep existing. A tool that holds your build hostage is one bad quarter away from being a liability, and no team should adopt one on a promise.
And we are not going to pretend the tool does something it does not, in the changelog or anywhere else, because the first reader who checks and finds it untrue stops trusting all of it.
If you are on a team like ours
The thing we would say to the version of us from two years ago is that the cost of not having this is real but invisible, which is why it never gets prioritised. Nobody schedules a fortnight for "the number was wrong in a place we did not think to look". It just happens, gets absorbed, and happens again next year with different people.
If you run a hardware team and any of the three failure modes above sounded like a Tuesday you have had, that is the audience. Founding teams is open for the first twenty student teams, and the changelog is the honest record of what has actually landed.