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 KodeBack and KodeProof are intended to solve.

We are opening conversations for two different programs.

Program 1: 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 2: 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 KodeBack:

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

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 KodeBack, use the Source Recoverability Assessment form at:

{KODEBACK_ASSESSMENT_URL}

For KodeProof, use the Private Refactor Trial form at:

{KODEPROOF_ALPHA_URL}

A useful introduction is also welcome, especially to:

• agency owners;
• technical directors;
• CTOs inheriting difficult applications;
• modernization leaders;
• platform engineers supervising AI agents;
• 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.