#Recovery
Resume an existing development from its actual state
To resume an existing development, we first need to understand its code, electronics, documentation and tests. We assess what can be reused and what needs rebuilding, without promising recovery before an audit.
Can you resume a development that has no documentation?
Yes, provided it is audited before anything is built. Missing documentation does not mean starting from scratch, but it does not let us assume everything can be kept either: that only becomes clear once what exists has been reviewed. That is why the first phase writes no new code. It inventories the material and records the actual state in which it was received.
A development can stall for very different reasons. We treat it as a recovery project and separate what works from what is only assumed to work.
Initial project assessment
The initial assessment is a scoped service that can be contracted separately, before deciding whether to recover the development.
Scope
- An inventory of what exists: designs, firmware and software, bills of materials, tests.
- The real state of each item.
- What to keep, rebuild or replace, and the open risks.
What we need from you
- Authorised access to the code, documentation or hardware.
- The tools used.
- The operating context.
What you receive
- A traceable report, with the evidence behind each finding.
- Options for continuing.
- You can use it with another supplier or your own team.
Terms
- Contracted separately.
- No obligation to continue with us.
- The exact scope is agreed per project.
Audit method
We start with an inventory of what really exists. Documentation may be missing entirely, the code may live on a laptop and the board in a cupboard.
Inventory
Designs, firmware and software, bills of materials, assembly tooling, tests and production records. Access must be authorised by someone entitled to provide it.
Assess each item
Can it run, be reproduced, be maintained: three questions per item. A missing component, a failing function and an unfinished integration are told apart.
Rebuild from the real thing
In electronics, the schematic is traced from the real board. In firmware, the work is based on execution: pin map, active peripherals and observed protocols.
Findings with evidence
Each finding is recorded with its evidence: a measurement, a file, a bench test.
Report
It can be verified and does not depend on the memory of whoever carried out the audit. Another team, or yours, can continue the work later.
Three questions for each item
What is kept and what is rebuilt
Not everything deserves rewriting. The audit classifies each item and documents the reason for each decision. The rule is to change the minimum needed to have a maintainable development again.
Kept
What works and can be reproduced. If the power electronics work and the problem lies in communications, the former stays.
Rebuilt
What cannot be maintained. If the firmware is stable but no sources exist, it is sometimes reimplemented module by module against the observed behaviour, keeping the protocols that already talk to your platform.
Replaced
What is no longer on the market. Obsolete components, discontinued connectors and services that no longer exist force substitution decisions, which are recorded as part of the scope.
With that classification we set out options for continuation, modification or replacement, rather than an estimate that treats an unreviewed system as already understood.
What cannot be rebuilt without more information
The audit also documents what cannot be rebuilt without additional data. That list defines the information requested from the client or operator and avoids committing to deadlines based on assumptions.
Not every project is recoverable to the same degree. The initial audit tells you this before any budget is committed. If code, access or test evidence is missing, we explain how that affects the assessment and which uncertainties remain open.
What we deliver
Indicative deliverables are an audit report with options, the recovered development working within the agreed scope, and documentation of its final state. Scope is agreed per project.
Audit report
With options for continuation, modification or replacement.
Recovered development
Working within the agreed scope.
Final-state documentation
A record of the state in which it was received and of what was done.
Schematics, sources and BOM
Traceable schematics and board design, versioned firmware sources, assembly and test documentation, updated bills of materials.
The next change of functionality or component then has a real starting point instead of becoming an audit from scratch. The work may include electronics, firmware, connectivity, software or integration with your existing tools; we reuse what works and coordinate the layers that need changes.
Because the audit is documented, you can take the report to another supplier or to your own team and still use it: it describes the state of the development, not our way of working. Whoever continues the work starts from the same record of what was kept, what was rebuilt and what remains open.
We work from Colmenar Viejo, Madrid, Spain. Describe the system and what prevents it from working. We assess what can be kept, which information is missing and the reasonable next step before committing to recovery.
Related services
Custom electronics development
From concept to product: hardware, firmware and connectivity.Firmware and embedded systems
The embedded software that makes your device work.Technology pilots
A limited test in your operation before increasing investment.Services index
All custom development services on one page.
Review the development you need to resume
Share its current state and material you are authorised to access.