Shipped Software Is Not Source Code

A company can have a working application and still have a source-code crisis.

That sounds contradictory until we separate two things that are often described with the same word: the software users receive and the source engineers need.

The deployed application is the finished artifact. It may contain HTML, JavaScript, CSS, images, shaders, WebAssembly, workers, packaged resources, manifests, and other files needed to run on a user’s device.

The engineering source is the maintainable project behind that artifact. It contains the original module structure, developer names, comments, types, tests, build configuration, dependency declarations, local assets, private packages, and the operational knowledge required to reproduce the release.

Those two surfaces can drift far apart.

What happens when software ships

Modern build systems transform source aggressively.

They may:

• combine hundreds of modules into a few chunks;
• shorten local variable and function names;
• inline functions and constants;
• remove unused code;
• split routes into lazy chunks;
• rewrite module boundaries;
• add runtime loaders and glue;
• convert framework templates or components into generated functions;
• extract, rewrite, or inline assets;
• compile TypeScript into JavaScript;
• package desktop files into an archive;
• produce browser-extension scripts for several execution contexts.

These steps are useful. They make software smaller, faster, and easier to deliver.

They can also discard information developers rely on.

The application may still behave correctly while the original local names, comments, file boundaries, and types no longer exist in the shipped result.

A working app can outlive its repository

The problem becomes commercially important when the engineering project is no longer trustworthy.

Common situations include:

• the repository was lost;
• the original developer left;
• a vendor delivered an incomplete handoff;
• production received hotfixes that were never committed;
• the build depends on a private package or service that no longer exists;
• the source maps are stale or reference paths that cannot be rebuilt;
• the source builds, but not into the application users currently run;
• an acquisition transferred the product but not the operational knowledge behind it.

The business still sees a functioning application. The engineering team sees an uncertain reconstruction problem.

Why “just use the files from the browser” is incomplete

A browser can download the files that were delivered to it. That is valuable evidence, but it is not automatically a development project.

The downloaded JavaScript may still contain:

• application code mixed with framework code;
• several versions of one dependency;
• dynamic imports whose routes were never visited;
• runtime-created URLs;
• hidden external services;
• asset paths that depend on the original server;
• anonymous variables whose role is visible only at runtime;
• protected strings that look safe to rename;
• framework-generated wrappers;
• code that boots only because donor-specific global state exists.

A folder of downloaded assets can preserve the artifact while still failing to restore ownership.

Source maps help—but do not finish the job

A good source map can recover authored file names, original source text, and mappings from generated code back to source.

That can eliminate a large amount of blind semantic work.

But source maps do not necessarily provide:

• a working package.json;
• exact dependency versions;
• private or modified vendor packages;
• the original build plugins;
• raw-loader or shader-import behavior;
• assets that were served from another origin;
• the correct application entrypoint;
• environment variables;
• authentication or realtime authority;
• proof that the recovered source now owns the running candidate;
• evidence that important user flows still behave like the deployment.

Source recovery and project promotion are related, but they are not identical.

What cannot be recovered exactly

Some information may be gone.

If a minifier changed a local variable from vehicleVelocity to a, the exact original name may not survive anywhere. The developer could also have chosen speed, carSpeed, v, or another reasonable name in the first place.

There is no single historical truth to recover unless the name was preserved in a source map, debug artifact, string, runtime label, or other evidence.

That does not make recovery useless.

The important question is not:

Can we reproduce every original keystroke?

It is:

Can we recover a clear, editable project that preserves the behavior and contracts the organization needs?

A good recovered name may be different from the original name and still be more useful to the next engineer.

What must remain exact

Other values are not merely style choices.

A short string may be:

• a route;
• a storage key;
• an event name;
• a serialized property;
• a server protocol field;
• an asset URL;
• a shader uniform;
• a GLTF node name;
• an Electron IPC channel;
• a browser-extension message or manifest entry.

Changing those values can break behavior while the code still parses, builds, and looks cleaner.

A recovery system therefore needs to distinguish local readability from external contract identity.

That distinction is one reason a global search-and-replace cleanup is unsafe.

The useful output is a workspace plus evidence

A meaningful source-recovery result should include more than source files.

It should explain:

• what deployment was captured;
• which application states were observed;
• which source maps or bundle routes were used;
• which dependencies were identified;
• which vendor regions were externalized, retained, or unresolved;
• which strings and entrypoints were protected;
• which behaviors were checked;
• which external services remain required;
• which areas were inferred;
• which areas remain unsupported;
• how the project builds and runs now.

That evidence is what lets a new engineer distinguish a measured recovery from a plausible reconstruction.

The KodeBack standard

KodeBack is being built around three surfaces:

1. The donor: immutable deployed bytes and captured behavior.
2. The evidence: derived reports, provenance, runtime observations, checks, history, and handoff material.
3. The candidate: the editable application engineers will continue maintaining.

The candidate is not allowed to become its own source of truth merely because it now looks cleaner.

A strong outcome is not “the source is original.”

A strong outcome is:

• the source is usable;
• the candidate can build and run for the declared environment;
• important contracts are preserved;
• captured flows are supported by configured evidence;
• dependencies and remaining authority are understood;
• uncertainty is explicit;
• the next change begins from a controlled workspace rather than a blank page.

That is software ownership recovery.