A Failure at This Stage Is the Cheapest Information You Will Ever Buy

The unit cracked on the third drop. The motor stalled at rated load. The seal leaked at 3 psi. The board browned out when the compressor kicked in. Whatever it was, the instinctive reaction is that the project is behind schedule. The accurate reaction is that you just bought a piece of information for the price of one prototype instead of the price of a tooling change, a production recall, or a warranty campaign.

The cost curve is well known: a change at prototype costs engineering hours, the same change after tooling costs a mold modification and weeks of schedule, and after launch it costs field service plus reputation. The question is never whether the failure is bad news. It is whether you extract everything it is willing to tell you before you touch the CAD.

Step One: Establish Exactly What Failed

Most teams skip straight to a fix and end up fixing the wrong thing. Before any design change, answer these in writing:

  • What was the exact failure mode? "It broke" is not a failure mode. "The boss adjacent to the screw sheared at the base, clean brittle fracture, no visible deformation" is.
  • Under what conditions? Load, temperature, humidity, cycle count, orientation, power state. Anything you did not record is a variable you cannot rule out.
  • Is it repeatable? One failure in one unit is an anecdote. Reproduce it on a second unit before you spend money.
  • Below spec, at spec, or above spec? A part that survives 2.4x the design load and then breaks is behaving as designed. One that fails at 0.6x is a genuine defect.
  • Was the test itself valid? Miscalibrated instruments, a fixture that added a load path, an operator who ran the wrong sequence. Verify the test before condemning the part.

Photograph the fracture surface, the wear pattern, the burn mark, and keep the failed hardware rather than printing a replacement. The physical evidence is the entire dataset. This is the discipline that separates a useful reliability test program from a series of expensive coin flips.

Step Two: Sort the Failure Into a Category

Nearly every prototype failure falls into one of five buckets, and the right response differs sharply by bucket.

  • Requirement failure. The part did what it was designed to do, but the requirement was wrong or never written down. The fix lives in the product requirements document, not in the CAD.
  • Design failure. Geometry, material, or margin was inadequate for a correctly stated requirement: stress concentration at a sharp corner, wall too thin, insufficient thermal path, undersized motor.
  • Build failure. The prototype does not match the design. A hand-soldered joint, a fastener at the wrong torque, an operator who missed a step. Very common and easy to mistake for a design failure.
  • Integration failure. Each subsystem works alone and the combination does not: motor drive noise corrupting a sensor, a power stage cooking nearby plastic, a resonance that only appears fully assembled.
  • Test failure. Fixture, instrumentation, procedure, or acceptance criterion was wrong.

Build limitations specific to prototyping deserve special attention. If a printed housing cracks, ask whether an injection molded version of the same geometry would have cracked, because printed parts are anisotropic and weak across layers. That is a process artifact rather than a design problem, as explained in print orientation and part strength, and confusing the two leads to redesigning a part that was fine.

Step Three: Treat the Cause, Not the Symptom

The rib cracked, so you thicken the rib. The unit reboots, so you add a bigger capacitor. Both are symptom treatments, and both tend to move the failure somewhere else rather than remove it.

Use a five-whys chain and write it down. The rib cracked. Why? Peak stress at its root exceeded the material's strength. Why was stress that high? The impact load path runs through the rib instead of the perimeter wall. Why? The mounting boss was placed to suit PCB layout, not structure. The real fix is at the fourth answer, and it is a better fix than a thicker rib. Where the physics is not obvious, instrument it: strain gauges, thermocouples, a current probe, high-speed video. A short FEA study that shows which of three geometry changes actually moves peak stress pays for itself in one avoided print cycle.

Step Four: Decide Whether to Change the Design or the Requirement

This is a business decision that engineers frequently make silently and badly. There are three legitimate options.

  • Change the design. Right when the requirement is genuine, the fix is bounded, and the cost is acceptable. Most cases.
  • Change the requirement. Right when it was arbitrary: a 6 ft drop spec on a countertop device, IP67 on a product that sees only a splash, a 10-year life on something customers replace in four. Relaxing an unjustified requirement is engineering, not cheating, provided you document the rationale. The exception is anything driven by a regulation or safety standard, covered in product safety testing requirements.
  • Change the scope. Ship version one without the feature that keeps failing. Painful and often correct.

Whichever you pick, decide it explicitly with the numbers in front of you: cost of the fix, schedule impact, residual risk. When margin rather than function is the question, factor of safety in mechanical design gives you a defensible place to land.

Step Five: Re-Test the Right Way

Change one variable at a time when you can. If you change four things and it passes, you do not know which change mattered, and you are carrying three modifications of unknown value into production cost. Re-run the full test, not just the step that failed, because fixes create new failure modes and a thicker rib shifts the crack to the adjacent wall. Re-test enough units to see the spread; one passing unit after one failing unit proves very little.

Then record the change. Even at prototype, a log with a reason, a revision letter, and the test result that justified it becomes the backbone of your engineering change order process later.

When Failures Cluster, Look Upstream

One failure is a design detail. Five unrelated failures in one build usually mean something structural: the concept is too ambitious for the budget, requirements were never nailed down, or the prototype build process is not controlled. That is the moment to step back and look at the patterns in common first-prototype mistakes rather than grinding through fix after fix. It is also worth checking whether the accumulated fixes are quietly making the product too expensive to build; price the bill of materials again after every third change.

Turn the Failure Into a Working Design

Projects House runs root cause analysis on failed prototypes, redesigns the parts that need it, and builds the next iteration with a test plan attached. Send us the failure description, photos of the hardware, and the test conditions through our contact form and we will tell you what we think actually happened.