What an Undocumented Prototype Actually Costs

Six months after a prototype works, somebody asks why the resistor on the sensor input is 4.7k instead of 10k. Nobody remembers. The engineer who changed it has moved on, there is no note, and the safe move is to leave it alone and never touch that circuit again. Multiply that across a hundred small decisions and you get a product nobody on the team fully understands, which is expensive in every direction: onboarding, cost reduction, factory transfer, and troubleshooting a field failure.

The reconstruction bill is real. Re-deriving why a prototype is built the way it is typically costs two to six engineering weeks on a moderately complex product, and sometimes it cannot be done at all, which means rebuilding from scratch. The prevention costs about twenty minutes a day during the build.

A Build Log: What Changed and Why

One document, appended to chronologically, never reorganized. Each entry: the date, what changed, why, and what happened afterward. Keep it in whatever tool the team will actually open, whether that is a shared doc, a wiki, or a text file in the repository. The tool matters far less than the habit.

The rule that makes a log useful is one change at a time. Change three things, see an improvement, and the log records that you changed three things. Change one, measure, record, then change the next, and six months later the log tells you exactly which one mattered.

Record the failures with more care than the successes. "Tried a 6 mm shaft, hub cracked at the keyway after about 400 cycles, went to 8 mm" prevents a future engineer from proposing the 6 mm shaft again as a cost reduction. The successful final state is visible in the hardware. The dead ends are only in the log, and they are usually the more valuable half.

Photograph Every Version Before You Take It Apart

Prototypes get cannibalized. The board from version two goes into version three, the motor gets reused, and version two ceases to exist. Once it is gone, so is every detail you did not capture.

  • Shoot before disassembly, always. All six sides, plus internals with the housing open and cables still routed as built.
  • Include a scale reference. A ruler or a coin in frame turns a photo into a measurement you can use later.
  • Capture cable routing and wire colors. This is the single most common thing nobody can reconstruct.
  • Save instrument screens. Scope traces, thermal camera images, and meter readings are data, and they are worthless a month later if not labeled with the conditions.
  • Name files so they sort. Date first, then version, then subject. A folder of numbered camera filenames is not documentation.

A short phone video walking around a working unit is worth more than a dozen stills, because it captures motion, sound, and the sequence of operation. It is also what you send to a manufacturer or an investor when explaining how the thing behaves.

Parts, Suppliers, and What They Really Cost

Start the bill of materials on the first day of building, not at the end. Every part that goes in gets a line: what it is, manufacturer part number, where it came from, what it cost at the quantity you bought, and the lead time you experienced. Add a column for what you would use in production if the prototype part is a placeholder.

Two things make this pay off. First, cost estimates built from a real prototype BOM are defensible in front of investors in a way that a spreadsheet guess is not. Second, when a part becomes unavailable, having the exact manufacturer part number rather than "the small brushless motor from the hobby site" is the difference between a phone call and an afternoon of reverse engineering. Structure it properly from the start using a real bill of materials.

Test Results Someone Else Can Re-Run

A result without its conditions is an anecdote. "Battery lasted 14 hours" means nothing without knowing the load, the temperature, the cell, and the firmware version.

Write the pass criterion before running the test, not after looking at the number. Record the setup, the instruments, the ambient conditions, the exact hardware and firmware revision under test, and the raw data rather than only the summary. Raw data can be reanalyzed when the question changes; a conclusion cannot.

This matters most when something fails. A failure with full conditions recorded is a diagnosable event; a failure remembered as "it got hot and shut down once" is not. How to work through those is covered in your prototype failed testing.

Files, Versions, and Where They Live

Firmware goes in version control with real commit messages. That is not negotiable and it is free. CAD and electronics files need equivalent discipline even without a PDM system: a dated release folder for each revision, a working folder that everyone knows is unstable, and a rule that nothing goes to a vendor from the working folder.

Export and archive neutral formats alongside native ones. A native CAD file is useless if your license lapses or your contractor changes tools, so keep STEP alongside it; the distinction and when each is needed is in STL vs STEP. For boards, archive the exact Gerbers and BOM that were sent to fabrication for each revision, because "the files that built rev B" and "the current files" diverge within days.

Once the design is released, changes need a small amount of process so the documentation stays true. Even a lightweight version of the engineering change order process beats an undocumented edit.

Where This Pays Off Later

Four situations turn a build log into money. Handing the product to a factory, where the manufacturing package is built directly out of what you recorded, as described in the manufacturing data package. Patent work, where dated records of conception and reduction to practice support your position; see the inventor's notebook under first-to-file. Regulated products, where a medical device requires a formal design history file and retroactive assembly of one is brutal. And investor diligence, where a technical reviewer who can trace decisions concludes the team is competent, which is a real part of the valuation.

Set Up Documentation That Someone Will Actually Maintain

Projects House builds prototypes with the record kept as the work happens: build logs, revision-controlled files, a live BOM, and test reports written to be repeatable. If you have a prototype that works and no documentation behind it, send us what exists through our contact form and we will tell you what it takes to capture it before the knowledge walks out.