KodeBack
Request an assessment

Ownership problems, not copying problems

Where a deployed application becomes an engineering question.

KodeBack is intended for organizations and engineers with a legitimate right to inspect and recover the software in question.

Missing or unusable source

The application runs, but the repository is gone, incomplete, corrupted, inaccessible, or unable to produce the live behavior.

Desired outcome: Establish deployed truth, assess recoverability, and create a maintainable candidate for a declared scope.

Former vendor or agency handoff

Production contains assets, code, configuration, or behavior the delivered repository does not reproduce.

Desired outcome: Produce an evidence-backed takeover package a new engineering team can continue from.

Production/repository drift

A repository exists, but nobody knows whether it represents the application users actually run.

Desired outcome: Compare source/build and deployed evidence, identify divergence, and recover supported missing surfaces.

Acquisition and technical diligence

A working client application has uncertain provenance, dependency closure, buildability, or maintenance ownership.

Desired outcome: Assess recoverability, runtime dependencies, vendor surfaces, hidden external authority, and residual risk.

Modernization without a blind rewrite

A team needs to replace a framework, toolchain, or vendor layer while preserving specific user behavior.

Desired outcome: Capture current behavior, recover a usable starting point, and define measurable retained flows.

Electron application recovery

A packaged desktop application contains renderer code, main-process startup, preload contracts, IPC, protocol handlers, resources, and native dependencies.

Desired outcome: Recover an editable desktop workspace and evaluate host behavior rather than treating the renderer alone as the product.

Browser-extension recovery

Background/service-worker registration, content scripts, page-world injection, messages, storage, and browser APIs create separate execution contexts.

Desired outcome: Preserve context, lifetime, message, storage, and injected-path contracts.

Scoped capability recovery

The organization wants one valuable experience but does not want to retain analytics, social, multiplayer, auth, or advertising.

Desired outcome: Declare retained behavior, prove removal closure where possible, and validate the kept flow.

Not a fit

A refusal is part of an honest recovery system.

  • ownership or authorization cannot be established
  • the goal is to reproduce another company’s product for unauthorized commercial use
  • required code is server-side and was never delivered to the client
  • access controls or encryption are expected to be bypassed
  • the buyer requires an exact reconstruction of deleted development history
  • no meaningful donor state can be accessed or captured
  • the acceptable result cannot include documented residual uncertainty

Take the next step

Start with the authorization and the trigger event.

The assessment path is designed to establish fit before sensitive artifacts are requested.

Request an assessment Read authorized use