Reverse engineering and re-implementation
Recovering a board nobody has source files for — and rebuilding it so you own it.
Sooner or later a product depends on a board that nobody has source files for. The designer left, the supplier discontinued it, or it arrived with an acquisition and the handover was a folder of PDFs.
Recovery
A structured teardown: photographic record at every layer, dimensional survey, part identification including the parts with the markings sanded off, and connectivity traced out into a netlist. The output is an annotated schematic that says explicitly where something is measured fact and where it is inference. That distinction matters — a recovered schematic presenting a guess as certainty is worse than no schematic.
Re-implementation
Recovery gives you understanding. Re-implementation gives you a board you can build for the next decade.
The interface and behavior stay identical, so it drops into the existing system. Everything underneath is redesigned with current, sourceable, second-sourced parts, a stack-up your fabricator can hold, proper test coverage, and a documentation package that belongs to you.
We have done exactly this on a Cube Orange+ flight controller carrier — teardown, analysis, then a clean-room re-implementation that became the basis for a new carrier design in a tube-launched UAV program.
Where we stop
Reverse engineering sits close to a line, and we would rather be blunt about it than discover a disagreement later. Recovering documentation for hardware you own, keeping your own product alive past a component’s end of life, and implementing published open standards are ordinary engineering work.
Cloning a competitor’s protected design is not work we take. We will ask what the basis is at the first conversation.
Common questions
Straight answers
Is this legal?
It depends entirely on the situation, and it is your call to make with your legal counsel — not ours. Recovering documentation for hardware you own, replacing an obsolete board in your own product, or re-implementing to an open published standard are ordinary engineering. Copying a competitor's protected design is not. We will ask what the basis is before starting, and we decline work where the answer is unclear.
What can realistically be recovered?
Connectivity, part identification, power architecture and mechanical interface recover well. programmed logic, firmware, calibration data and anything inside a marked-off package generally do not. We tell you where the boundary sits before quoting, so nobody is surprised halfway through.
Why re-implement instead of copying?
A copy inherits every obsolete part and every undocumented decision. A re-implementation keeps the interface and the behavior while replacing the internals with parts you can buy, a stack-up your fabricator can build, and documentation your team can maintain. The board becomes an asset instead of a liability.
Have you actually done this?
Yes — a full teardown and clean-room re-implementation of a Cube Orange+ flight controller carrier, feeding a new carrier design for a tube-launched UAV application.