Knowledge & Insights
Engineering: prototyping boundaries & iteration
Engineering claims often go wrong at the same fault line: where does “routine build” end and qualifying R&D begin, especially when projects move quickly from concept to prototype to pilot production.
This guide focuses on the real-world boundary questions: iterative design loops, test failures, scale-up challenges, and the point at which uncertainty is resolved and work transitions into industrialisation, certification, and BAU manufacturing.
1) The boundary: prototypes vs production
A prototype can be a single unit, a set of test coupons, a bench rig, a pilot build, or even a pre-production run. The number of units is not the deciding factor, the boundary is about why you are building it.
- Building to prove whether a design is technically feasible under real constraints.
- Testing competing design options and learning what works (and why).
- Iterating materials, geometry, tolerances, control logic, or manufacturing approach to overcome failures.
- Resolving uncertainty around performance, reliability, thermal/structural behaviour, manufacturability, or safety.
- Repeating a proven design to meet demand.
- Routine drawing updates, documentation, and standard work instructions.
- Process tuning for yield/cost once the technical unknowns are settled.
- Routine QA checks, rework, and manufacturing support.
A useful litmus test
If you already know what “good” looks like and you are simply executing known steps to achieve it, you’re likely in BAU. If you are building and testing because you don’t know whether the design/process will achieve the required capability, you’re likely in R&D.
2) Iteration: what “systematic” looks like in engineering
Reviewers respond well to engineering narratives that show an iterative loop: hypothesise → design → build → test → analyse → redesign. It doesn’t need to be academic, it just needs to show that you were making informed technical decisions under uncertainty.
Hypothesis & constraints
What capability was required (loads, temperatures, torque, cycle time, tolerances, safety factors)? What constraints made it difficult?
Design options
Competing architectures, geometry changes, material selections, control strategies, or manufacturing routes, with reasons for each.
Test outcomes
Failures and unexpected behaviour are often the strongest evidence, they show the solution wasn’t readily deducible.
“Iteration” isn’t the number of prototypes you built, it’s the evidence that each iteration was informed by new technical learning.
3) Common prototyping scenarios and eligibility signals
Below are common engineering scenarios where prototyping happens. Each can be qualifying or non-qualifying, the signal is where the uncertainty sits.
New product or subsystem design
Often qualifying where you’re pushing performance (weight, strength, power density, thermal margins, vibration, acoustics) and the design outcomes are not predictable from established practice.
Design for manufacturability (DFM)
Can qualify where manufacturability is uncertain (e.g., thin-wall distortion, heat-affected zones, surface finish, yield issues) and requires experimentation to find a viable process window.
Materials & coatings trials
Strong signals include unexpected wear modes, adhesion failures, corrosion behaviour, thermal cycling issues, or fatigue performance that required iterative trials and analysis.
Controls & embedded integration
Often qualifying where real-world operating conditions create unstable behaviour (noise, drift, latency, coupling effects) and the control strategy had to be experimentally tuned or redesigned.
4) Tooling, jigs, fixtures and pilot lines
Engineering prototyping is rarely just “the product”. The work can sit in enabling tooling, fixtures, and pilot equipment, particularly where the company is trying to achieve a capability that standard tooling cannot deliver.
Where tooling can be R&D
If the tooling itself required novel engineering to achieve required precision, cycle time, repeatability, or safety, and the outcome wasn’t readily deducible, it can form part of the R&D narrative as enabling technology.
Pilot builds / trial runs
Useful when you’re testing whether a process is stable at scale, not just whether a single prototype works.
Process windows
Parameters (feeds/speeds, temperatures, cure cycles, clamping forces) tested to overcome failure modes.
Metrology & repeatability
Where measurement itself becomes a constraint and requires new approaches to validate outputs reliably.
5) Testing: failures, redesign and what to evidence
Test failures are often the most compelling part of an engineering claim, provided you show how the results informed design changes. The goal is not to list every test. It’s to show the tests that demonstrate uncertainty and the steps taken to resolve it.
Good evidence examples
- Test plans and acceptance criteria tied to the uncertainty.
- Failure reports (fracture, delamination, overheating, resonance, leakage, drift).
- Root cause analysis (e.g., FMEA, 5-Why, fishbone) that drives redesign.
- Iteration logs showing what changed and why.
What to avoid
- Only including pass results with no learning narrative.
- Over-reliance on generic “we tested it” statements.
- Certification-only evidence where the core uncertainty was already resolved.
- Presenting routine QA checks as R&D without deeper technical context.
6) Certification, standards and compliance work
Standards and certification often sit alongside prototyping and can look similar on paper (plans, tests, documentation). The key distinction is whether compliance activity is simply demonstrating that a known solution meets requirements, or whether it is driving technical iteration because meeting the standard is itself uncertain.
A balanced way to frame it
If meeting a standard required you to overcome non-obvious technical constraints and redesign the product/process to achieve it, that redesign work can support the R&D narrative. Purely administrative compliance and routine certification steps are typically better treated as non-qualifying.
7) Costing: how to apportion mixed projects
Engineering projects almost always contain a mix: exploratory prototyping, design iterations, testing, industrialisation, procurement, and routine production support. A strong claim is explicit about that mix and applies a consistent methodology.
- Workstream-led split: allocate costs to the specific workstreams where uncertainty existed (design, prototyping, test, redesign).
- Role realism: engineering, design and test roles may be high; procurement, project admin and routine QA should be treated carefully unless clearly linked to the experimental work.
- Prototype build costs: materials and consumables used in prototyping/testing are often easier to support when linked directly to iterations and test plans.
- End-point clarity: mark when uncertainty is resolved and ring-fence industrialisation and BAU thereafter.
Reviewers typically prefer a claim that is focused and plausible over one that tries to pull the whole project into R&D.
8) Practical checklist
- Have you clearly defined the uncertainty being resolved (and why it wasn’t readily deducible)?
- Is your prototype described as a way to prove or disprove technical feasibility under constraints?
- Do you show a loop of test → learning → redesign?
- Have you documented the point at which the solution became “known”, and industrialisation began?
- Do the cost apportionments reflect the technical narrative and the actual delivery roles?
Want to sense-check a prototype-heavy engineering project?
We’ll help you separate qualifying iteration from industrialisation, tighten the narrative, and apply a clear methodology that reflects how your team actually builds.
Request a call back