What We Are Looking for in Our First Design Partners

Kalu Kode was founded in 2026 and is still at the beginning of its commercial work.

We are bootstrapped, founder-led, pre-revenue, and have not proven market fit.

The software and research are real. Customer validation is not.

The next step is not to manufacture a launch story. It is to work closely with a small number of organizations that have the actual problems KodeCapture, KodeBack, KodeAtlas, and KodeProof are intended to solve.

We are opening conversations for four different programs.

Program 1: KodeCapture Early Access

KodeCapture is for situations where a deployed web application is the most authoritative artifact available and must be preserved before it changes, disappears, or enters recovery.

We are looking for organizations that can say yes to most of the following:

• You own the application or have explicit authorization to capture it.
• The deployed version is accessible in a controlled environment.
• Routes, requests, storage, runtime state, or interactive behavior matter to the outcome.
• A static download or screenshot archive would not preserve enough evidence.
• You can identify the states and interactions that matter most.
• You have a technical owner who can review capture and replay limits.
• You understand that unobserved server behavior cannot become replay authority.

Strong early situations may include pre-migration preservation, agency handoff capture, high-value Three.js/WebGL experiences, and evidence preparation before source recovery.

Program 2: KodeBack Source Recoverability Assessment

KodeBack is for situations where deployed software still works, but a maintainable source project is missing, stale, incomplete, vendor-controlled, or no longer reflects production.

We are looking for organizations that can say yes to most of the following:

• You own the application or have explicit authorization to recover it.
• The deployed version is still accessible.
• The source repository is missing, incomplete, unbuildable, or materially behind production.
• The software matters enough that a rewrite or abandonment has real cost.
• You can identify the user flows that must remain.
• You have a technical owner who can meet regularly and validate the result.
• You are willing to begin with a scoped paid assessment rather than a promise of full recovery.
• You can explain the business event creating urgency.
• You understand that unsupported or unresolved surfaces may remain.

Strong early situations may include:

• an agency taking over an abandoned client application;
• a CTO inheriting a production/repository mismatch;
• an acquisition with an incomplete software handoff;
• a high-value web, Electron, extension, or interactive application that no longer has a safe edit path;
• a modernization effort that needs one critical capability preserved;
• a former vendor or developer no longer available.

The assessment is intended to determine whether recovery is practical, what route applies, what evidence exists, and what should happen next.

It may recommend not proceeding.

Program 3: KodeAtlas Context Early Access

KodeAtlas is for teams whose important development context is scattered across Git history, pull requests, issues, reviews, tests, decisions, and agent sessions.

The current KodeAtlas foundation is a deterministic, resumable, verifiable Git and GitHub archival CLI. The early context program is intended to evaluate the next TypeScript/JavaScript vertical: symbol history, evidence-backed context packets, durable code anchors, and agent-facing delivery.

We are looking for organizations that can say yes to most of the following:

• You have one TypeScript or JavaScript repository, monorepo, or related repository set with meaningful history.
• Developers or agents regularly ask why a function, contract, or subsystem is implemented the way it is.
• Relevant rationale is spread across commits, pull requests, issues, reviews, tests, or documentation.
• File paths and line links become stale after moves, renames, and refactors.
• You can identify real implementation tasks where better historical context should change the plan.
• You can review whether a context packet is useful, sufficiently cited, and honestly incomplete.
• You are willing to evaluate local-first workflows before team coordination or enterprise deployment is assumed.

Strong early situations may include mature TypeScript codebases, agent-heavy engineering workflows, monorepos with repeated refactors, and systems where institutional knowledge is leaving faster than documentation can keep up.

Program 4: KodeProof Private Refactor Trial

KodeProof is for engineering teams using AI agents on risky changes where a plausible diff and passing build are not enough.

We are looking for bounded tasks such as:

• monolith decomposition;
• module or package moves;
• helper consolidation;
• public CLI changes;
• artifact or schema hard cuts;
• generated or recovered-source cleanup;
• initialization-sensitive refactors;
• dependency transition across a small wave.

A strong partner can provide:

• one repository the organization is authorized to use;
• one exact task with a clear objective;
• the normal project checks;
• a technical champion;
• an agreed model and harness;
• permission to collect sanitized workflow metrics;
• time to review true catches, false blocks, and usability;
• willingness to compare the result with ordinary agent practice.

The purpose is not to prove that KodeProof makes every AI change safe.

It is to learn whether its transaction model improves control, evidence, and delivery for a specific class of work.

What “design partner” means here

A design partner is not a passive beta tester.

The relationship should include:

• access to a real problem;
• regular technical review;
• candid workflow feedback;
• procurement and security reality;
• agreement on what success means;
• a bounded scope;
• a commercial commitment;
• permission to retain sanitized, non-proprietary measurements;
• a path to a larger engagement when the result is useful.

We are not asking partners to design the website or validate a predetermined pitch.

We are asking them to help discover what the product must become to solve a repeatable business problem.

What we are not looking for

We are not looking for:

• unauthorized recovery or copying;
• access-control circumvention;
• credential or secret extraction;
• “clone this competitor” work;
• a free open-ended migration;
• a repository with no owner or technical champion;
• a task whose success cannot be defined;
• a partner that needs guaranteed recovery before assessment;
• a request to weaken safety gates to force a green result;
• an exclusive relationship that controls the general roadmap.

Curiosity is welcome in public discussion.

The design-partner programs require a concrete problem.

What partners should expect from us

Kalu Kode will:

• be transparent about company and product stage;
• separate measured facts from recommendations;
• define the scope before mutation;
• protect confidential material;
• preserve authorization and data-handling requirements;
• report unresolved areas;
• avoid using a partner’s name publicly without permission;
• distinguish internal evidence from customer evidence;
• keep the first engagement narrow;
• document what the system did and did not establish;
• treat false blocks and failed recoveries as product findings, not as facts to conceal.

Because the company is founder-led, partners will work directly with the person building the system.

That creates speed and technical depth.

It also means capacity will remain intentionally limited.

What the first conversation covers

For KodeCapture:

• the deployed application and authorization boundary;
• priority routes, states, and interactions;
• authenticated or sensitive surfaces;
• expected capture and replay outcome;
• known external services and data constraints.

For KodeBack:

• the deployed application;
• ownership and authorization;
• source condition;
• business trigger;
• critical flows;
• services and data;
• technical constraints;
• desired outcome;
• assessment scope.

For KodeAtlas:

• repository shape and language;
• the historical question developers or agents cannot answer reliably;
• available Git, GitHub, issue, review, test, and decision evidence;
• one or more target symbols or tasks;
• local-first, privacy, and model-provider constraints;
• how context usefulness and citation quality will be reviewed.

For KodeProof:

• repository and language;
• agent/harness;
• refactor objective;
• protected contracts;
• current validation;
• previous failures;
• acceptable cost and time;
• trial data and confidentiality.

A first conversation is not a sales demo disguised as discovery.

The goal is to determine whether the problem fits.

Why we are publishing this now

Kalu Kode has spent substantial time on internal architecture, recovery research, evidence systems, and controlled AI change workflows.

The biggest remaining risk is not another technical feature.

It is building the wrong commercial product around a problem nobody will prioritize.

The only honest way to reduce that risk is to work with real organizations.

Apply or make an introduction

For KodeCapture, request early access at:

https://kodecapture.com/request-access/

For KodeBack, request a Source Recoverability Assessment at:

https://kodeback.com/assessment/

For KodeAtlas, discuss context early access at:

https://kodeatlas.com/early-access/

For KodeProof, apply for a Private Refactor Trial at:

https://kodeproof.com/private-alpha/

A useful introduction is also welcome, especially to:

• agency owners;
• technical directors;
• CTOs inheriting difficult applications;
• modernization leaders;
• platform engineers supervising AI agents;
• maintainers of mature TypeScript or JavaScript systems;
• engineering-productivity teams.

Please include the problem, urgency, authorization status, and the person who will own the technical evaluation.

We expect to learn that some of our assumptions are wrong.

That is the point of the program.