From whiteboard sketch to working hardware in weeks, not quarters
Rapid prototyping turns a concept into a physical, functioning thing quickly enough that you learn from reality instead of from meetings. It removes the long feedback loop that kills momentum: months of specification and CAD before anyone holds the device, discovers the ergonomic problem, or watches a user try to plug the cable in upside down.
Willowark optimizes each iteration for the question it needs to answer. An early loop might be a 3D-printed shell over a development board with hand-soldered wiring — ugly on purpose, because its job is to test the interaction, the fit, or the physics. Later loops tighten toward the real design as questions get answered. The discipline is refusing to polish anything the current iteration is not asking about.
R&D & PrototypingHow the work gets done
The same way every time: scope, build, hand over.
The practical toolkit spans both domains. On hardware: FDM and SLA printing for enclosures and mechanisms, laser-cut and machined parts where stiffness or tolerance demands it, dev boards and breakout modules (ESP32, STM32 Nucleo, Raspberry Pi class) before custom PCBs, then quick-turn boards once the circuit stabilizes. On software: firmware that is honest about being prototype-grade, simple UIs for exercising the device, and logging built in from the first revision, because a prototype that cannot report what it did teaches you little. Each build cycle ends with structured trials, not vibes — what got measured, what surprised us, what the next revision changes.
Momentum is the deliverable underneath the deliverables. A healthy prototyping engagement produces a revision every one to three weeks, a growing decision log of what was tried and why, and a design that converges because each loop retired a real question. By the end you hold hardware you can put in front of users, investors, or your own production team — with a documented trail from sketch to artifact.
Every revision starts with a one-line statement of what it is meant to find out, and a plan for how we will know. Fit questions get answered by handing the print to the people who will hold it. Physics questions get answered with a measurement, not an impression — a thermal camera on the enclosure, a logic analyzer on the bus, a scale under the mechanism. When a build cycle ends without a clear answer, that is treated as a planning failure to fix in the next loop, not a reason to add another week of polish. The point is to keep the number of open questions shrinking on a schedule.
Some iterations exist to kill an idea. A mechanism that binds, a battery budget that does not close, a sensor placement blocked by the user's hand — learning that in a printed part costs days; learning it after tooling costs far more. We log those results with the same care as the wins, because the record of what was ruled out is what stops the next engineer from trying it again. All CAD, firmware, and notes are delivered in editable source form, and the handoff includes a list of what is validated, what is still a guess, and what a production design would have to replace.
Scope it in writing
What we agree before work starts
- Functional prototype hardware, iterated across agreed build cycles
- Prototype firmware and supporting software with logging
Build with checkpoints
Working results, not slide decks
- CAD models and design files for every revision
- Trial results and decision log from each iteration
Hand over something you own
Documentation, source, and training
- Recommendations and open-questions list for the next engineering phase
- Bill of materials per revision with lead-time and cost-driver notes
Sound familiar?
Where rapid prototyping earns its keep.
A founder with a napkin-sketch device who needs something demonstrable in front of pilot customers
An OEM exploring a product-line extension that marketing wants to see and touch before committing
A fixture concept the production team wants to trial on the line before tooling is ordered
An interaction question — button, screen, or app? — that only a working unit can settle
Ask about Rapid Prototyping
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 rapid prototyping project.
How functional will the prototype actually be?
As functional as the questions require, which we define together up front. Some prototypes need only look and feel right; others must run the full sensing and control loop for days at a time. We scope each iteration against explicit questions so you are never paying for polish that teaches nothing.
Do we own the designs and code?
Yes. CAD files, schematics, firmware, and software produced in the engagement are yours, delivered in editable source form, not just outputs. That includes the intermediate revisions, because the record of what was tried is part of the value.
Can a rapid prototype evolve straight into the production design?
Parts of it can, and we architect with that in mind — but a prototype optimized for learning speed and a product optimized for manufacture, cost, and compliance are different artifacts. The honest path is a deliberate product engineering phase that carries forward the validated decisions and replaces the shortcuts. We flag, throughout, which is which.
What if we do not know exactly what we want yet?
That is normal at this stage, and prototyping is how you find out. We start with the one or two things you are surest about and the biggest thing you are unsure about, build to test that, and let the rest of the definition emerge from the results. Requirements get written down as they get validated, so by the end there is a specification grounded in what worked rather than in what was imagined at the start.
How many iterations should we plan for?
Usually three to six get a concept from sketch to something demonstrable, but the honest answer depends on how many open questions there are and how many can be tested in a single build. We plan in cycles rather than a fixed count, agree the question for each cycle before starting it, and check at each review whether another loop is earning its cost. Stopping early because the questions are answered is a good outcome, not a shortfall.
Where this sits
Rapid Prototyping, 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.