Taking over the maintenance of an electronic product built by another provider: where to start?

Start by collecting everything needed to rebuild the product: source code, build tools, manufacturing files, documentation and server access. Then have this material audited to find out what works, what is missing and what is fragile. Fixes come afterwards, in small releases tested on the real product.

What should you collect from the previous provider?

Everything needed to rebuild and ship the product without them:

• the complete source code of the firmware, apps and servers, with its history if possible;
• the build tools: compiler and version, scripts, dependencies, update signing keys;
• the circuit board files: schematics, layout, bill of materials, manufacturing file;
• the documentation: architecture, protocols, test and production procedures;
• the accesses: code repositories, servers, app store accounts, domain names.

Check what your contract says about the ownership and handover of these items. For a specific case, ask your legal adviser.

How do you know the recovered code is complete?

By rebuilding it. Firmware compiled from the recovered sources, loaded onto a board and tested proves that nothing essential is missing. If it does not compile, or behaves differently from the product in the field, a piece is missing: a dependency, a build option, a more recent version of the code.

What should the audit cover?

• The state of the code: structure, technical debt, fragile or undocumented parts.
• The state of the tools: reproducible build or not, existing tests, continuous integration.
• Security: outdated dependencies, updates, key management.
• Components: those approaching end of life.
• A list of priorities: what is urgent and what can wait.

Where should the fixes start?

With a first release that changes almost nothing: it validates the whole chain, from the build to updating the products in the field. Then come the bugs that bother your customers most, then new features. Each release is tested on the real product before delivery.

Should the product be rewritten?

Rarely at first. Existing code that works in production has value: it handles real cases met over time. A gradual rework, part by part, limits the risks. A full rewrite is justified when the audit shows the code base can no longer evolve.

How we can help

Picodev takes over products developed by other teams: audit, corrective and evolutive maintenance, security updates, component obsolescence.

Related service: Maintenance and takeover