Turn a working prototype into a product you can manufacture, certify, and support
Product engineering is the disciplined distance between a prototype that works on the bench and a product that survives manufacturing, shipping, customers, and firmware updates in the field. It removes the trap that catches many hardware teams: a compelling demo that quietly cannot be built at cost, cannot pass EMC testing, or cannot be updated after unit one thousand ships.
Willowark treats this phase as risk retirement in a deliberate order. Cost and manufacturability constraints come in early, because they reshape designs; compliance requirements are mapped before the enclosure is final, because they reshape everything else. The prototype's validated decisions carry forward; its shortcuts — the hand-tuned threshold, the dev board, the power supply that works on the bench — get engineered out one by one.
R&D & PrototypingHow the work gets done
The same way every time: scope, build, hand over.
The work spans the whole artifact. Electronics move from dev boards to custom PCBs designed for assembly, test points, and the EMC review ahead. Firmware gets hardened: watchdogs, brownout handling, fault logging, and a secure, recoverable update path, because a bricked field unit is a support call that costs more than the unit. Mechanical design absorbs DFM feedback from the actual manufacturers quoting it — draft angles, fastener count, assembly sequence. Alongside the design we build the documentation manufacturing runs on: BOMs with sourced and second-sourced parts, assembly drawings, and end-of-line test specifications.
The measure of success is unglamorous and absolute: units built by people who did not design them, passing a defined test, at a cost that closes the business case. We plan pilot builds deliberately — small runs that shake out assembly and test problems while they are cheap — and treat every pilot discrepancy as a documentation bug to fix before scale.
The phase opens with a requirements pass the prototype never had: operating and storage temperatures, drop and vibration expectations, ingress rating, regulatory markets, expected service life, and the cost target at the intended volume. Each of those turns into a test the design must pass, and the test plan is written before the design is changed, so the engineering has something concrete to aim at. Where a requirement is unknown — nobody has decided whether the device ships to Europe — we flag it early, because that decision changes the radio module, the labeling, and the paperwork, and it is cheaper to decide now than to redesign later.
Cost is engineered, not discovered. We identify the handful of components that dominate unit cost — usually a display, a radio module, a sensor, or the enclosure — and pursue alternatives, consolidation, and second sources for those first, with the trade-offs written down. The manufacturing package is delivered in the native formats your fabricators and assemblers use, and every file is yours. When the product ships, you also hold the record of why each decision was made, which is what lets a future revision — a cost-down, a new market, a replacement for an end-of-life part — happen without re-deriving the design from scratch.
Scope it in writing
What we agree before work starts
- Production-intent electrical, mechanical, and firmware design
- Manufacturing package: BOM, assembly drawings, and fabrication files
Build with checkpoints
Working results, not slide decks
- End-of-line test specification and fixtures or procedures
- Compliance plan and pre-certification test support
Hand over something you own
Documentation, source, and training
- Pilot build support with documented issue resolution
- Unit cost model identifying the dominant cost drivers and evaluated alternatives
Sound familiar?
Where product engineering earns its keep.
A startup whose funded prototype now has to become five hundred sellable units
An internal tool a company built for itself that customers now want to buy
A product failing EMC pre-scans that needs board and enclosure revisions before certification
A device with field-update requirements the prototype firmware was never designed for
Ask about Product Engineering
Describe the problem. Get a straight answer.
One line is enough. An engineer replies within a business day.
Related work
X-ray thickness gauge
Components:
- X-ray source (+ detector): Source and detector pair measuring attenuation through the material.
- Acquisition (signal chain): Signal conditioning and acquisition.
- Gauge software (thickness model): Calibrated model converting attenuation to thickness.
- Line control (feedback): The line's controller, closing the loop on thickness.
Connections:
- X-ray source to Acquisition
- Acquisition to Gauge software (calibrated)
- Gauge software to Line control (thickness)
An industrial measurement company · Industrial measurement
X-ray thickness gauge
A complete X-ray based thickness gauge: equipment assessment, hardware selection, electrical and hardware engineering, API integration, all software, and commissioning — delivered as a working instrument.
Read the case study →Common questions
Asked before every product engineering project.
How much of our prototype will survive into the product?
The decisions survive more than the parts. Validated algorithms, sensor choices, and architecture usually carry forward; dev boards, hand-built wiring, and prototype firmware structure usually do not. Early in the engagement we audit the prototype and give you an explicit keep, rework, replace list so the plan is visible.
Do you handle certifications like FCC and CE?
We design for them and manage the process: identifying applicable standards early, designing with EMC and safety in mind, running pre-scans to catch problems before formal testing, and preparing the technical documentation. The accredited testing itself happens at certified labs, and we coordinate that work and respond to any findings.
Can you work with our contract manufacturer?
Yes, and we prefer to engage them early — DFM feedback from the people actually quoting and building the product is worth more before the design freezes than after. If you do not yet have a CM, we can help you evaluate candidates against the product's volume, process needs, and test requirements.
What volume does product engineering make sense for?
Lower than many teams assume. Even a run of a few dozen units benefits from a real BOM, an assembly procedure someone else can follow, and a defined test, because the alternative is the original engineer hand-building each one. What changes with volume is how far to push cost optimization and tooling: at low volumes we favor machined and printed parts and off-the-shelf modules; injection molding and custom silicon only pay off when the numbers say so.
Our prototype was built by someone else. Is that a problem?
No, as long as we can get the files and, ideally, an hour with whoever built it. We start with an audit that reverse-documents what exists — schematics, firmware structure, mechanical constraints — and produces the keep, rework, replace list. Missing documentation adds time to that audit but rarely changes the outcome. What matters more is whether the prototype's core decisions are sound, and the audit tells you that either way.
Where this sits
Product Engineering, inside a r&d & prototyping system.
The lit component is the part of the system this service delivers; the rest is what it has to work with.
Hover or focus a component to see what it is and what it talks to. Arrow keys move between them.
Requirements become a bench prototype with real sensors and firmware; a test rig produces data; a pilot unit runs in the field; and the design is handed to production with everything documented.
Components:
- Requirements: What it must measure, survive and cost.
- Bench prototype (MCU + sensors): Dev board, real sensors, real signal chain.
- Firmware: Acquisition, processing, comms, update path.
- Test rig (data): Instrumented tests against known references.
- Pilot unit (in the field): A handful of units where the product will live.
- Production (handoff): Drawings, BOM, test procedure, firmware — yours.
Connections:
- Requirements to Bench prototype over handoff
- Bench prototype to Firmware
- Firmware to Test rig over serial
- Test rig to Pilot unit over handoff
- Pilot unit to Production over handoff
Strategy. Software. Systems.
Have a system that should exist?
Tell us what your operation is doing manually, what isn't connected, or what you're trying to build. We'll tell you plainly whether and how we can help.