SiliciumHex FieldKit

Design to Cost · Evaluate

Prototype Costing

Cost the prototype build honestly: it reveals the real process costs the estimate guessed.

  • Time45 min
  • FormatTeam
  • StageEvaluate

Prototype Costing: what it is and why it works

Prototype Costing treats the first physical build as a measurement campaign for the cost model. Instead of booking prototype spending as a lump of development expense, the team records material consumed, labor hours by operation, machine time, scrap, rework and purchased items with the same structure as the production estimate. Every difference between what the estimate assumed and what the build revealed is logged, explained and fed back into the Should-Cost Model. Prototype-specific effects, such as one-off setups or hand fitting that will not occur in series, are separated from genuine process costs that will persist.

The method works because estimates are built on assumptions, and the prototype is the first chance to test many of them at once. Weld hours, fit-up problems, machining times on difficult features, cable routing effort and test durations are all notoriously hard to estimate from drawings. Measuring them early turns C-grade guesses into B- or A-grade values while the design can still change. The approach reflects concurrent engineering practice, where manufacturing reality informs design before release. It connects to Estimate Confidence Grading, whose grades it upgrades, to Variance Analysis, which uses the same estimate-versus-actual logic in production, and to DFM/DFA, which acts on the surprises the prototype reveals.

What you need

  • The current production cost estimate, broken down by operation and part
  • A time and material booking structure matching that breakdown
  • The prototype build plan, with who records what
  • A list of the assumptions the team is least sure about

What you get

  • Measured prototype cost per operation and part, in the estimate's structure
  • A surprise log: where reality beat or lost to the estimate, and why
  • Separation of prototype-only effects from recurring production effects
  • Updated should-cost model values and confidence grades
  • A list of systematically optimistic estimating factors to correct

When to use it

When estimates meet their first physical reality.

How to do it, step by step

  1. Cost the prototype build with the same rigor as production: material, labor, machine time.
  2. Record every surprise: where did reality beat the estimate, where did it lose?
  3. Update the should-cost model with the measured values.
  4. Identify which estimates were systematically optimistic.
  5. Feed the corrections into the next phase estimates.

Worked example: Costing the first build of a mobile screening plant chassis

Illustrative scenario — figures are realistic but not from a real company.

A mining equipment maker built two prototypes of a new track-mounted screening plant. The production estimate put the welded chassis at 118 labor hours and the hydraulic installation at 46 hours. The design-to-cost team asked the shop to book hours by operation rather than to the prototype project as a whole.

  1. Supervisors recorded hours on eight chassis operations and five hydraulic operations for both builds, plus material scrap and rework.
  2. The chassis took 171 hours on the first build and 152 on the second. About 20 hours were prototype effects: manual layout and a jig built during the job. The rest came from fit-up of the side members, where plate cut tolerances forced grinding.
  3. Hydraulic installation took 71 hours. Hose routing through the chassis required three reworks, and fittings had to be changed from straight to angled types.
  4. The team separated the one-off effects, kept the recurring ones and updated the model.

Result. The recurring chassis estimate rose to about 135 hours, and a design change to tabbed-and-slotted plates was launched to bring it back toward 115. Hose routing was redesigned with a clipped manifold. The weld-hour factor for heavy fabrications was found to be optimistic by roughly 15% and was corrected for future estimates.

Common pitfalls and how to avoid them

  • Booking all prototype hours to one project code, which makes them useless for estimating.Set up a booking structure that mirrors the estimate before the build starts.
  • Treating every prototype overrun as a production cost.Tag each surprise as prototype-only or recurring, and correct the model only for recurring effects.
  • Dismissing all overruns as prototype effects.Require a specific explanation for any overrun classified as one-off; if none exists, treat it as recurring.
  • Recording surprises but not changing the estimating factors.Update the should-cost model and the estimating database with the measured values, and note which factor was wrong.

Frequently asked questions

How do you estimate production cost from a prototype?

Record material, labor and machine time per operation during the prototype build, then remove effects that will not recur in series, such as one-off setups, manual layout or temporary fixtures. Apply the expected production process, batch sizes and learning curve to the recurring values. The prototype gives measured data points; the production estimate still requires judgment about how those values will evolve.

Why are prototypes so much more expensive than production parts?

Prototypes carry one-off setups, manual operations, rush procurement, low purchasing volumes, iterative rework and no learning-curve benefit. Tooling is often temporary or replaced by machining. That is why prototype price is a poor proxy for production cost, while prototype hours per operation, carefully recorded, are a valuable input to the production estimate.

What should be recorded during a prototype build?

Hours by operation, material consumed including scrap and offcuts, purchased items and their prices, machine time, rework and its causes, inspection and test durations, and every problem that required a workaround. Recording in the same structure as the production estimate makes comparison straightforward.

Origin

Learning from physical validation — concurrent engineering practice (Boothroyd-Dewhurst tradition).

Used in these playbooks

Cost redesign sprint 1 week

One week to redesign the expensive parts: analyze functions, run the workshop, apply DFM rules and cost the prototype honestly.

  1. Functional Analysis
  2. Value Engineering Workshop
  3. DFM / DFA Review
  4. Prototype Costing

Related methods

More in “Evaluate”

Grade the estimates and price the risks before deciding.