Software ownership recovery · Research-stage · Authorized use only
KodeBackhelps authorized teams turn deployed web, Electron, and browser-extension applications into editable source workspaces—with evidence showing what was recovered, what remained protected, and what is still uncertain.
Not a cloning service. Not a promise of the original author’s exact source. Recovery is scoped to the deployed evidence and behaviors that can be captured and evaluated.
The problem
The source repository can be missing, incomplete, years behind production, controlled by a former vendor, unable to build, or full of generated output nobody can safely maintain.
The application still runs. The business still depends on it. But every change begins with uncertainty.
Common triggers include a vanished vendor, production hotfixes that never reached version control, an acquisition without a maintainable build, a blocked platform migration, or one valuable capability that needs to survive while others are removed.
Before and after
The goal is not historical perfection. It is an editable candidate whose evidence, protected surfaces, and residual uncertainty are explicit.
Drag mode · Evidence surface
Compare the kind of artifact KodeBack starts with against the structured candidate it can produce after source-map, bundle, and behavior analysis.
Drag the divider or use the arrow keys to inspect both source surfaces.
Illustrative interface only. Actual recovery output depends on the captured application, available source maps, runtime evidence, and the declared scope.
Recovery, not recreation
A coding agent can recreate a screen from a prompt. That does not tell it which assets were loaded lazily, which request changed state, which storage key survives a reload, which package version shipped, which WebSocket frame initialized the scene, or which short string is an external contract.
KodeBackbegins by preserving the deployed application as evidence. Recovery proceeds through bounded stages that can be checked, recorded, retried, or refused.
A recovered workspace is valuable when the handoff explains the limits of the source, the behavior, and the remaining uncertainty.
The candidate remains tied to captured routes, runtime observations, dependency findings, protected contracts, and an explicit unresolved-region matrix.
Recovery toolchain
KodeBack’s research context spans deterministic capture, browser inspection, visual/runtime evidence, and source analysis. The React Bits mark identifies the visual reference for this surface; it is not a runtime dependency of the recovery pipeline.
Preserve the shipped artifact before interpretation changes the evidence surface.
01Separate application code, generated output, runtime behavior, and vendor regions before cleanup.
02Deliver an editable candidate with the remaining seams, limits, and next actions visible.
03Process preview
Capture the deployed application, its assets, routes, runtime environment, requests, storage, and supported realtime behavior into an immutable evidence surface.
Determine whether the application is source-map-first, readable-bundle, blind, or hybrid. Do not force every application through the same path.
Fingerprint vendor families, exact or likely versions, bundler runtime, modified vendor code, and ambiguous regions before cleanup.
Inventory routes, storage keys, event names, serialized fields, asset paths, shader strings, extension contracts, IPC channels, and other contracts.
Promote trustworthy source maps, lift readable bundles where appropriate, retain uncertain bytes when necessary, and mutate only when evidence supports it.
Run configured smoke, boundary, behavior, browser, scene, console, network, and project checks for the declared states.
Package the editable workspace, evidence, change history, remaining seams, and next actions so the next engineer does not restart from bundle archaeology.
Use cases
Establish what production actually contains before another agency or internal team takes ownership.
Determine whether the repository can reproduce the deployed product and recover missing client-side changes where supported.
Capture behavior and dependencies before replacing frameworks, build systems, or runtime surfaces.
Treat host startup, preload, IPC, extension contexts, service-worker lifetime, and packaged resources as first-class evidence.
Declare the behavior that must remain, then remove or replace unwanted capabilities through a scoped, evidence-backed plan.
What the assessment returns
The assessment is valuable even when full recovery is not advisable.
Honest limits
KodeBackdoes not need the original developer’s exact variable names to produce useful source. It also cannot recover facts that were never shipped or observed. A strong result is a candidate that is editable and independently runnable for the declared scope, with important contracts protected, captured states evidenced, dependencies clearer, and residual uncertainty explicit.
KodeBack Journal
Read how donor authority, source maps, vendor provenance, semantic cleanup, and parity shape a maintainable recovery.
A model’s confidence is not a rename safety threshold. Reliable automation needs adjudicated examples, independent evidence, risk curves, and a protected-surface veto.
Frontend code is expected to be recoverable. Risk rises when recoverable logic includes secrets, entitlement decisions, privileged host channels, or server-authoritative rules.
A recovery workspace becomes safer when deployed bytes, derived evidence, and editable source have different owners and different authority.
The Kalu Kode product family
Four distinct products share one evidence-first philosophy and remain independently useful.
Preserves the observable truth of deployed software as replayable evidence.
Early accessRecovers maintainable source from software that still runs.
You are herePreserves why the code became what it is and delivers that context where change begins.
Archive foundation · context in developmentControlControls what AI-authored changes reach the repository.
Private alphaTake the next step
Tell us about the application, the authorization you have, and the outcome you need. We will determine whether a scoped assessment is appropriate before proposing a larger engagement.
