What a Source Recovery Assessment Should Tell You

A working application is not enough information to price or promise a recovery.

Two products can look equally complex in a browser and have completely different recovery profiles.

One may ship complete source maps, public dependencies, and static assets that can be promoted into a buildable candidate quickly.

The other may depend on missing private packages, authenticated services, WebSocket state, native modules, runtime-loaded assets, and a bundle with no useful boundaries.

The first commercial step should therefore be an assessment, not a universal fixed-price promise.

The assessment question

A useful Source Recoverability Assessment should answer:

Can this deployed application be turned into an independently buildable and maintainable source workspace for the declared product scope, and what evidence supports that conclusion?

That is more precise than:

Can you decompile this?

The buyer does not only need readable text.

They need a path to ownership.

1. Authorization and scope

The assessment should begin with the rights and the outcome.

Questions include:

• Does the organization own the software or have explicit authority to inspect and recover it?
• Which deployment is authoritative?
• Which user journeys matter?
• Which capabilities may be removed?
• Which services must remain live, become local, or be replaced?
• Is the goal emergency maintenance, modernization, vendor transition, diligence, or a scoped feature recovery?
• Which platforms matter: browser, Electron host, extension contexts, workers, or others?
• What data may be captured and retained?

A technically recoverable application may still be a poor engagement if the scope, authorization, or data handling is unclear.

2. Donor access and capture quality

The deployed application is the behavioral authority.

The assessment should identify what can actually be observed:

• public routes;
• authenticated routes;
• required accounts or roles;
• storage and session state;
• network requests and responses;
• WebSocket traffic;
• service workers;
• dynamic assets;
• runtime configuration;
• interaction paths;
• error and edge states;
• Electron host or extension contexts;
• browser and device requirements.

A static download is not automatically a replayable donor.

The report should say which states were captured, which were unavailable, and which still depend on the live origin.

3. Recovery-route classification

Not every asset should enter the same pipeline.

The assessment should classify the application or its regions into routes such as:

Source-map-first

Useful sourcesContent or mappings provide authored source or strong structure.

The remaining work may be promotion, dependency closure, asset recovery, build configuration, and runtime validation.

Readable-bundle lift

The shipped code is already understandable enough to port into explicit legacy boundaries without blind semantic recovery.

Bundle-unpack

Bundler module boundaries survived and can be reconstructed mechanically.

Blind semantic recovery

Important first-party regions are minified or scope-hoisted without authoritative source.

Runtime and static evidence will be needed for names and ownership.

Hybrid

Different chunks or regions require different routes.

A truthful assessment may conclude that only a subset is economically sensible to recover.

4. Source-map quality

The presence of a .map file is not the conclusion.

The assessment should report:

• maps discovered locally or at authorized donor URLs;
• mapping validity;
• sourcesContent coverage;
• authored versus vendor entries;
• duplicate transformed variants;
• stale or conflicting paths;
• entrypoint evidence;
• source that references unavailable private packages;
• styles, shaders, workers, and assets omitted from the map;
• whether the mapped source can actually own the candidate boot.

Source maps can recover source text while leaving the runnable closure incomplete.

5. Dependency and vendor provenance

The report should distinguish:

• exact public packages and versions;
• probable package families;
• donor-vendored or modified code;
• private or missing packages;
• bundled singletons and addons;
• mixed first-party/vendor wrappers;
• dependencies whose public replacement has a different module shape;
• runtime services that are not npm dependencies.

The buyer needs to know what can be installed normally and what must remain captured, be replaced, or be supplied by the organization.

6. Asset and runtime closure

A recovery can compile while missing the files that make it useful.

The assessment should inventory:

• images, fonts, video, and audio;
• GLB/GLTF, textures, HDR, Draco, Basis/KTX, and shaders;
• WASM modules;
• workers and service-worker assets;
• configuration payloads;
• CMS and API data;
• generated manifests;
• Electron resources and native modules;
• extension-injected files;
• runtime-created URLs;
• zero-byte, blocked, or origin-dependent assets.

For each surface, the report should state whether the candidate can become independent of the donor.

7. Protected contracts

Some literals and identities should be preserved even when the code around them is cleaned.

The assessment should identify likely protected surfaces:

• routes;
• storage and cookie keys;
• events and message types;
• network payload keys;
• asset URLs;
• shader names and source;
• model node names;
• package exports;
• worker paths;
• extension context contracts;
• serialized data;
• public CLI or configuration surfaces.

This creates the safety policy for later cleanup.

8. Behavioral authority and parity plan

The assessment should define what “works like the original” will mean.

That may include:

• boot;
• route transitions;
• forms and validation;
• storage persistence;
• API and network behavior;
• error states;
• realtime updates;
• visual states;
• canvas or 3D scene structure;
• input response;
• reload and restart;
• Electron process lifecycle;
• extension message flows;
• performance-sensitive behavior.

The result should list the exact states and the evidence that can be collected for each.

Parity is always scoped to observed and declared conditions.

9. Maintainability target

The assessment should agree on what the deliverable needs to support.

Possible levels:

Recovery baseline

Runnable, editable source with evidence and explicit residuals. Large or generated regions may remain.

Engineering handoff

Clear first-party/vendor boundaries, documented build/run path, protected contracts, and bounded cleanup debt.

Change-ready outcome

A fresh engineer or agent can perform a defined follow-on change without returning to the donor bundle.

The highest level should be demonstrated through a maintainability exam, not inferred from aesthetics.

10. Risk and refusal

A good assessment can recommend against recovery.

Reasons may include:

• insufficient authorization;
• donor state cannot be observed;
• critical private dependencies are unavailable;
• essential backend behavior cannot be reproduced or retained;
• native/DRM/anti-tamper surfaces fall outside support;
• source maps are misleading;
• the desired scope depends on removed capabilities;
• the likely cost exceeds a controlled rebuild;
• data-handling requirements cannot be met;
• evidence is too weak for the promised outcome.

A refusal can save the buyer from an expensive false start.

11. The deliverable

A KodeBack assessment should provide a concise decision package:

• executive summary;
• declared scope;
• authorization statement;
• donor and capture inventory;
• route classification;
• source-map report;
• dependency and vendor provenance;
• asset/runtime closure;
• protected-surface inventory;
• proposed behavior scenarios;
• unsupported or unresolved surfaces;
• preliminary candidate where feasible;
• recovery phases;
• estimated effort range and assumptions;
• security and data-handling plan;
• go, narrow, gather-more-evidence, or do-not-proceed recommendation.

The report should separate measured facts from recommendations.

What the buyer should be able to decide

After the assessment, the organization should know whether to:

• proceed with a scoped recovery;
• recover only one valuable capability;
• supply missing source or dependencies;
• retain a live service temporarily;
• replace a risky vendor surface;
• choose a clean rebuild instead;
• pause because the evidence is insufficient.

That decision is the product.

The first paid step should reduce uncertainty before either side commits to a large migration.