Sources and scope, October 9, 2026. Deck v30.2 has 12 slides. It keeps v30.1 and adds the benchmark scope on slide 5, the first-customer profile on slide 8, founder build facts on slide 9, why the architecture lasts on slide 10, roadmap targets on slide 11 and the seed ask on slide 12. The architecture slide now comes before the plan. These notes support the claims, examples and assumptions in that cut. Industry studies describe the problem. The Kin benchmark measures a narrow research workflow. Customer outcomes and the business model remain to be validated.
"Patent pending" is included at the founder's explicit request on October 7, 2026. U.S. provisional patent application 64/117,353 was filed July 22, 2026, with Troy Fortin, Jr. as inventor. In plain terms it covers a code repository whose authoritative record is a versioned, tamper-evident graph of code entities and their relationships, with change-impact verification and reproducible search built on it. Slide 10 condenses that to one line. A provisional application is not a granted patent, and the deck makes no claim about the scope of claims a later application will receive.
Faros AI, April 2026, and the AI Engineering Report 2026 compare organizations' periods of low and high AI adoption across 22,000 developers and more than 4,000 teams. The report compares the two lowest-AI quarters with the two highest. Median time in review increased 441.5%, rounded to 442%. Pull requests merged without review increased 31.3%, rounded to 31%. These remain April findings, explicitly dated on the cards. They do not describe the latest review duration in every organization.
Faros's September 2026 Speed Trap summary reports monthly incidents up 125.4%, rounded to 125%. It studies the latest 12 months of telemetry from 22,000 developers across 4,000 teams as already-high AI adoption deepens. The public summary does not specify exact calendar endpoints or comparison windows. Findings are observational. This is total incident burden, not failure probability per change; incidents per PR rose 14.5% in this study.
The same article describes unreviewed merges rising 76.3% in its body but calls 76.3% a share in its FAQ. Because those meanings differ, the slide retains April's unambiguous 31% growth figure. The newer article provides no replacement numeric review-duration figure. Its 300.6% increase concerns QA time, not code review.
Qodo, September 23, 2026: 25.8% of 500 US developers named reviewing and validating AI code as their main delivery bottleneck. A separate survey of 300 leaders found 26.0%. These are survey shares, not elapsed time. The study also reports unchanged review duration with greater cognitive effort for 36.4% of developers.
New Relic and Hanover, June 10, 2026: 82% of 200 US IT and engineering decision-makers reported a production failure tied to AI-generated code in the previous six months. This is self-reporting rather than incident telemetry. It supports the problem but is a different measure from monthly incident growth.
Harness and Sapio, July 29, 2026: 72% of 700 respondents reported unexpected AI cost spikes or bills, but the question covers all enterprise AI, rather than coding tools specifically. Sombra, October 6, 2026: 63% of 1,000 US and Canadian developers said employers responded to rising AI costs. Responses can include monitoring or usage restrictions and do not necessarily indicate budget overruns. Neither number replaces the coding-specific bill metric.
Mavvrik and Benchmarkit, 2026 State of AI Cost Governance (July 29, 2026; report page) reports that 39% of enterprises said coding-tool costs exceeded expected license or usage costs. The survey covered 396 enterprises in April and May 2026. Mavvrik sells AI cost-governance software. This is reported budget overrun incidence, not measured dollars or the size of an overrun. It does not imply that Kin would eliminate those overruns.
SWE-Pruner, arXiv 2601.16746, 2026, measured token use on SWE-bench Verified with Mini-SWE-Agent. Read operations accounted for 76.1% of total tokens with Claude Sonnet 4.5 and 67.5% with GLM-4.6. Slide 3 rounds the first figure to 76%. This is a result for a particular model and benchmark, not a universal reading share or a measure of dollars. The discount illustration explains why connections can require investigation; it is not the task used in SWE-Pruner. Slide 3 now names Cart total, Checkout amount and Receipt line as connections to check, matching the recorded answers on slide 4. Dashed paths represent uncertainty in the illustration. Additional branches terminate in question marks because the three named examples are not meant to imply that the full reach of a real change is known upfront. The statement about repeated investigation is conditional on lacking a shared record; neither the study nor the illustration establishes that all reading can be avoided or that human reviewers consume model tokens.
Kin architecture and recorded history describe code entities and recorded relationships as repository state, with native commits, branches and merges. Source content is preserved in content-addressed storage, and parsed code entities refer to spans of that content. Kin records content, entities and relationships together. People can use the CLI, and agents can query through MCP. Language and workflow support are limited, and recorded relationships can be incomplete.
Kin runs alongside Git and supports bounded import, coexistence and export workflows. Kin history and Git history remain distinct. The architectural thesis is that code relationships should participate in the repository's own change model. Existing products also retain graphs, context and history. A graph aligned to a revision alone is not unique to Kin. The expected benefits for review and reliability need matched evaluations of preparation effort and finished work.
The published saved session was captured September 16, 2026 on Kin 0.7.19, macOS arm64, using four TypeScript source files written for the example. Kin build commit: e534618359cad9e1788f6a7b7488378d4f570bb1. Binary SHA-256: 8eeb59b6af13d97ba69352898fba109724a4391081e2a4860fef201c815f3816. The run used CPU embeddings.
The command kin refs applyDiscount --kind calls returned cartTotal, checkoutAmount and receiptLine. The edit capped the discount at half the price. Kin recorded native change 5d094ad61bdfbfbcdda0819887dfd78dffacfb5253907834af93317d549b66e6, with 2 entities and 25 relations. A new shell returned the same three callers and showed the change in Kin's log.
Before: return price - (price * percent) / 100;
After: const discount = Math.min((price * percent) / 100, price / 2);
return price - discount;Slide 3's plain-language "Max discount 100%" to "Max discount 50%" display is conceptual shorthand. At a 100% input, the original function permits a full-price discount; the new function caps it at half the price. The original function does not contain an explicit 100% maximum check. The slide is an explanation of the policy change, not a literal code diff or a claim that the earlier function validated the input range.
Slide 4 labels the same three callers as Cart total, Checkout amount and Receipt line. A scripted MCP find_references request returned these callers plus three module import/reference rows, so its full payload was not identical to the CLI's filtered callers output. The diagrams simplify this saved result; they are neither interface screenshots nor full graph exports. The caller relationships did not change during the example.
The new shell queried the repository's running daemon. This demonstrates scoped continuity after a source-body edit, not a daemon restart, complete relationship coverage, comparative speed or reduced review effort. The saved example is historical rather than a current-release rerun. Slide 4's review, reach and token benefits are intended outcomes, not measured reversals of the industry statistics on slide 2.
The October 7, 2026 benchmark used 8 questions about React and Flask, each run with 3 seeds, for 24 paired runs. These are 8 distinct questions, not 24 distinct tasks. Questions were written blind in ordinary developer language and sealed. Both sides used the same local model, qwen/qwen3.8-27b, at medium effort, with identical settings, wording and seeds.
File search let the model search and read source files. Kin used an unreleased answer-first build: Kin supplied an answer before the model's first step, and the model could ask Kin follow-up questions but had no file-reading, search or shell tools. Kin's setup had been tuned on 24 earlier development questions about the same two projects and frozen before the sealed run.
Total prompt and completion tokens, summed over model turns without prompt caching, were 79,553 for Kin and 849,673 for file search: 90.6372% fewer, rounded to 91%. Kin used fewer tokens in all 24 pairs, with reductions of 78% to 93% by question kind. The two zero-baseline bars show the total token count on each side, with the Kin bar drawn to 9.3628% of the file-search bar's width. The frozen exact-function-name scorer marked 24 of 24 Kin runs and 22 of 24 file-search runs correct. This score is limited to these questions and this scoring rule; it does not establish generally superior correctness. Kin completed 19 of 24 runs in one model turn, rounded to 79%; file search completed none in one turn and used 3 to 9 turns.
First response and zero-token lookup. Nineteen of the 24 runs (79.1667%, shown as 79%) produced a scored-correct final answer in the agent's first model turn with zero follow-up tool calls. This is the agent's correct-without-follow-up rate, not an independently graded accuracy percentage for Kin's initial answers. The initial Kin reply for each question was identical across seeds, while the agent sometimes chose different follow-up behavior. The remaining five runs made follow-up queries and also finished correctly.
The frozen answer-first adapter queried Kin before the model's first turn, then inserted Kin's response into the prompt. Its deterministic router and graph lookup recorded zero LLM tokens for all 24 initial answers and nine follow-up routes. This supports zero LLM tokens for the lookup itself. It does not mean the full AI exchange was token-free or that the agent merely copied the reply verbatim. All outer-agent runs consumed tokens, totaling 79,553; the 19 one-turn runs consumed 39,018. One example used 1,103 prompt tokens and 389 completion tokens, for 1,492 total. Agents could reason about and format the supplied answer. The experiment graded final agent answers, not raw lookup replies.
The line "Kin supplies the map so AI can focus on the work" expresses the product thesis behind this mechanism. A client could display a deterministic lookup result directly without a model generating the response, but this benchmark did not measure that end-to-end mode. Indexing, graph preparation and other non-LLM compute are separate from query-time token counts. The source evidence is the sealed result bundle, raw router log and frozen run_preask3.py/run_ask3.py adapters; no new benchmark was run for this deck revision.
Earlier held-out runs on October 4 used differently worded questions and had the model call Kin's tools itself. They matched file-search accuracy at about three times the tokens. The October 7 result concerns the different, answer-first workflow. Its limits are one local model, two repositories, read questions only, an unreleased build and no measured speed comparison. Token counts do not establish customer bill savings. Editing success, production reliability and broader repository coverage require separate evaluations. The results file is available on request.
Scope line on slide 5. "Sealed" means the plan, questions and adapters were frozen with hashes before the run, and the launcher refuses changed files. "Held-out" means the 8 questions were not among the 24 development questions the answer-first setup was tuned on; both sets come from the same two repositories, React and Flask.
The scenario assumes a 200-developer team and four distinct categories of potential value. All reductions are assumptions, not measured Kin outcomes. Green identifies the proposed solution categories; it does not imply that the industry increases on slide 2 have been reversed. The first three categories value engineer capacity. Only the fourth models a reduction in AI token spend.
Review: $521,488, shown as $520K. 200 developers × 6 hours/week × 46 working weeks × an assumed 10% net reduction = 5,520 hours returned. The six-hour baseline includes preparing code for review and reviewing others' code. It comes from Bosu and Carver's 2013 survey of open-source developers, cited by Bosu et al., 2015. It is not a contemporary measurement of Kin users. The 46 weeks and 10% reduction are scenario assumptions.
Unreviewed changes: $45,347, shown as $45K. Assume improved review prevents 10 non-incident post-merge fixes per month, each requiring 4 net engineer hours: 10 × 4 × 12 = 480 hours/year. Both the avoided-fix count and hours per fix are hypothetical inputs, not sourced industry averages or measured product results.
Production: $45,347, shown as $45K. Assume earlier checks avoid one production incident per month requiring 40 total engineer-hours across responders: 1 × 40 × 12 = 480 hours/year. Incident frequency avoided and effort per incident are hypothetical inputs. This category includes engineer effort only; it adds no downtime revenue loss, customer compensation or reputational value.
Labor valuation. The BLS software-developer wage of $135,980 for May 2025 and a 69.2% wage share of compensation from BLS ECEC Table 4, June 2026 professional and related occupations, give $135,980 ÷ 0.692 ÷ 2,080 = $94.472543/hour. This includes benefits, with no extra overhead multiplier. Calculations use the unrounded rate; the slide displays $94.47. These are capacity valuations, not assumed payroll reductions.
The bill: $136,800, shown as $137K. 200 developers × an assumed $300/month in variable AI usage × 12 × an assumed 19% bill reduction = $136,800/year. This is an illustrative usage budget, not an industry average. Dollar spend alone does not establish a moderate or heavy AI adoption level; the slide does not assign either label. The monthly budget excludes fixed seat subscriptions. The 19% bill reduction is a separate modeling assumption, not a measured Kin result and not a conversion of reading's token share into dollars. Input, output and cached tokens have different prices; realized savings also depend on usage, contracts and how the released capacity is used.
Spending evidence. LinearB's 2026 benchmarks cover 253 organizations, 83,000 developers and 2.7 million pull requests from February through May 2026. They report directional monthly token costs of $50, $152 and $481 per developer with some AI use in the Fair, Good and Elite organization bands, with $481 at the 90th percentile of spend. Anthropic's current Claude Code documentation reports enterprise usage averaging $150–$250 per developer/month, without a sample size or measurement period. Jellyfish's April 15, 2026 analysis of 12,000 developers at 200 companies in Q1 2026 estimates monthly token costs at $52.38 median, $226.58 at the 75th percentile and $691.14 at the 90th, using published Claude API pricing rather than invoices. These support a range of usage; none establishes $300 as typical. LinearB classifies moderate use from the share of coding days involving AI (at least 20%), not from a dollar threshold. A $300 budget is plausible but cannot establish that adoption class.
Scale Venture Partners' May 26, 2026 survey of 38 portfolio and network companies reports a $577 median and $1,040 mean per engineer/month for code generation. It includes seats and tokens, excludes inference serving their products and sometimes uses a broader R&D denominator. Its exact spending month is undisclosed. This supports the plausibility of heavier total spending but does not validate a token-only budget. Public pages checked October 7, 2026.
Spending sensitivity. At $150 per developer/month, the same assumed 19% bill reduction gives $68,400/year in AI savings and $680,582.08 in total modeled value. At $500, it gives $228,000 in AI savings and $840,182.08 in total value. These are alternative budgets for the same 200-developer team, not additional benefits. The labor assumptions stay unchanged.
No overlapping hours. Review is net review/preparation effort after allowing for any additional review coverage. Post-merge rework excludes review and production incidents. Incident response excludes the review and routine-fix hours already counted. The two added categories therefore represent separate hypothetical effort, not a second valuation of the 5,520 review hours. Their assumed benefits must be tested independently.
Total: $521,488.44 + $45,346.82 + $45,346.82 + $136,800 = $748,982.08/year, rounded to approximately $750K for one 200-developer team. Card values are independently rounded and need not sum exactly to the rounded total. This is potential gross economic value before KinLab fees, implementation effort and other operating costs. It is a scenario, not a forecast or demonstrated customer return.
Potential benefits outside the estimate. Fewer mistakes and less repeated investigation could shorten the time to deliver. Fewer incidents could help protect reputation and customer retention. No dollar value is assigned to these possibilities, and the deck does not present them as measured Kin outcomes. They are not added to the review, rework or incident-response hours above.
The phrase "As AI use grows, so can the value" describes a conditional business thesis. More active users and more intensive agent use can increase variable AI spend, repeated context work and the number of changes that need verification, even with the same 200-person team. Faros's September research associates deeper use with greater downstream load while also finding that some earlier quality problems ease. LinearB's 2026 benchmarks associate heavier use with higher merge rates and show rising costs among the heaviest spenders. Neither study measures Kin or proves that its benefits scale proportionally with AI adoption.
The ~$750K is one scenario, not a ceiling or a forecast. Realized value depends on workload, avoidable effort, usage prices, Kin's effectiveness and operating costs. As a sensitivity example, doubling variable AI spend from $300 to $600 per developer/month, with the same assumed 19% reduction, doubles only the AI category from $136,800 to $273,600. Holding labor assumptions fixed gives $885,782.08 total gross annual value, not twice the original total. Review, rework and incident assumptions must be evaluated separately. Higher adoption alone does not justify increasing all four cards.
Kin is free and open source for developers and teams who operate it themselves. KinLab is the managed team platform in development. The proposed first core subscription is $40 per developer seat per month. Slide 7 shows free Kin and paid KinLab side by side, with core paid benefits prominent. Potential pooled hosted-agent and automation usage, optional managed-service add-ons, and custom enterprise packages remain a small secondary expansion line. This is a hypothesis for buyer and cost discovery, not approved pricing or an available commercial offer.
Developer subscriptions would expand with team adoption. Usage would expand with compute actually operated by KinLab, including hosted agent and automation work, rather than charging for every local agent or context query. Optional managed pipelines and advanced governance packages are possible add-ons; packaging, entitlements and prices are not settled. Enterprise deployment and support arrangements are likewise proposed. Included usage, meters, rates, gross margins and willingness to pay require validation. No unlimited-agent promise, revenue forecast or package for a single team size is implied.
The intended paid value is managed organizational operation: shared code context across repositories, coordinated reviews and releases, and team and agent access controls. Free Kin also includes repository history, local review, notes, coordination and federation. KinLab is not the only way to get those underlying capabilities. The business model concerns operating and governing a shared service around them. Add-ons would build on the same code, context and change history; this is an architectural and packaging thesis, not a proven cost or feature advantage over GitHub or other services.
The October 7 local product audit checked the KinLab README and source contracts for reviews, agent policies, release governance, pipelines and billing. Code presence establishes implementation work, not a deployed or generally available service. General hosted coding-agent execution is a planned extension; managed pipeline execution has source implementation. Organization-wide narrative memory is explicitly planned and currently returns no cards, so the slide does not promise it. Existing billing meters are not commercial validation. The willingness-to-pay research task remains open.
Cursor Teams lists $40 per user/month and additional model usage. Devin billing combines $40 full seats with pooled consumption and additional credits, subject to its plan minimum. CodeRabbit combines developer plans with separately metered cloud-agent minutes. Sourcegraph describes enterprise pricing with included and additional usage. These are relevant billing patterns, not validation of KinLab's price or margins. Augment's flat team plans provide a counterexample; per-developer billing is a testable choice, not an industry necessity. Public pages checked October 7, 2026.
The $40 starting price is selected for discussion after the founder requested a tentative per-developer model with hosted agent charges and add-ons, then asked to emphasize only the first core per-seat proposal. The expansion line does not promise those services are included in the $40 subscription. Slide 6's gross value scenario does not establish willingness to pay or subscription ROI. At $300 of monthly variable AI spend and an assumed 19% reduction, modeled AI savings are $57 per developer/month before any KinLab fee or usage. Most of the scenario's value is engineering capacity, not AI cash savings.
Gartner estimates the broader enterprise AI coding-agent market at $9.8B–$11.0B annualized as of April 2026. This includes coding assistants, AI-native IDEs, terminal agents and agentic platforms. It is a point-in-time annualized category estimate, not completed-year revenue or Kin's TAM/SAM. The figure is retained here as background; the revised slide 7 focuses on the pricing model. A bottom-up reachable market still requires defined target segments and supported account counts. No market share, adoption rate or revenue forecast is implied.
Our proposed strategy has two routes into a shared foundation. Bottom-up: one developer gets value from less repeated investigation and better AI context, shares it, and helps the organization recognize broader cost, review and coordination value. Top-down: AI bills, delivery friction or risk prompt leadership to sponsor an evaluation, set a standard and roll the platform out to teams. The diagram puts Kin at the center, with developers building momentum upward and leadership driving adoption downward and inward. The routes converge on a KinLab evaluation and possible organization-wide expansion.
These are hypotheses for how adoption could happen, not measured conversion, committed customers or evidence that a CTO or CISO has mandated Kin. A CISO is a possible stakeholder, not a claim of certification or a promise that Kin eliminates security risk. Enterprise governance and hosted services remain in development. The Git/GitHub analogy has been removed at the founder's request; the slide now explains adoption instead of product equivalence.
The published team direction and architecture support the intended shared platform. Kin v0.8.1 was published September 27, 2026, following the September 26 public beta. Public availability of local Kin does not establish readiness of all main-branch features or KinLab. The deck demonstrates no paying teams, committed design partners or revenue.
First customers. The slide 8 profile, teams of 20 to 200 developers building with AI agents on large codebases, is the segment we will recruit design partners and pilots from first. It reflects where repeated investigation costs the most and matches the operating model's 25-seat team assumption. It is a targeting choice, not a description of existing customers. The closing line "Start with one team. Build repeat use. Expand with KinLab." is the October 8 v30.1 wording.
"I built Kin after spending my own money on AI that kept losing context and sending me back to fix its work" is the restored personal origin sentence, as requested. It summarizes my account of spending my own money on AI, repeated investigation, wasted tokens, stale context and rework during the October 7 deck discussion. The supporting credentials are hands-on AI engineering at The Home Depot and building Kin as a self-funded project into public beta. The company biography corroborates the Home Depot experience and creator role; the earlier founder deck records self-funding, and the public release supports product availability. The slide links to LinkedIn and the public Kin repository. The repository identifies itself as public and includes Troy's signed origin story; its public author mapping and Troy's verified GitHub profile corroborate authorship. These facts do not imply a Home Depot deployment or customer relationship.
Build facts, checked October 9, 2026 against the public repository. 123 GitHub releases of Kin, the first on June 24, 2026 and the latest public release v0.8.1 on September 27, 2026 (release list). 14 languages with full extraction of code entities and their relationships: TypeScript, JavaScript, Python, Go, Java, Rust, C++, C, Kotlin, C#, Ruby, Swift, PHP and HCL/Terraform, with depth varying by language. More than 17,600 automated tests, counted as Rust test attributes on the main branch. Kin was built by directing coding agents, which is how Troy builds most of his software. Troy goes full-time on Kin when the seed round closes; today he works on Kin alongside employment, with written approval of the scope.
The layout follows the October 7 Fireflies advice at 37:48–41:34: one personal sentence about experiencing the problem, supported by concise background and ability-to-build evidence. The portrait, name, role and two credentials replace the earlier narrative paragraphs. Sequoia's pitch guidance and YC's presentation guidance informed clarity and hierarchy, not the founder's factual claims.
GitHub and GitLab. GitHub's Git documentation describes file snapshots, commits and branches, with hosting, pull requests and collaboration built around Git repositories. Its code navigation links definitions and references using Tree-sitter for supported languages. GitLab Orbit adds both Remote and Local graph approaches: Remote indexes code and software-development data into a managed graph; Local parses a repository and stores definitions and cross-file references in a local DuckDB graph, accessible through the CLI or MCP. This category therefore includes more than hosting alone.
Sourcegraph and Augment. Sourcegraph's precise code navigation uses language-specific SCIP indexes generated from repositories and uploaded to the Sourcegraph instance. Augment's Context Engine semantically indexes code, maps relationships across code and services, and retrieves context including commit history and external documents. Both provide code understanding beyond text search; the comparison does not claim that Kin alone has graphs, context or history.
Entire. Entire combines Git hosting, agent-session storage and search. Its semantic graph runs locally and maps code symbols and relationships. Agent checkpoints link code changes with prompts, reasoning and tool calls, and sessions connect to Git history. Local graph computation and in-repository session storage should not be described as a single external service.
Agent Trace. The Agent Trace specification, version 0.1.0, January 2026 RFC, records AI contributions alongside human authorship, with conversation references and associated line ranges. Trace storage is left to each implementation; it need not be an external service or a particular Git storage mechanism. Cognition announced support on January 29, 2026. Agent Trace is an open specification supported by multiple organizations, not a standalone competing company. Cognition's article presents possible uses and mock management-tool examples, not comparative Kin evidence.
Kin's thesis is that tracked content, its recorded connections and their history belong in the repository's own change model. Kin runs alongside Git today. The selected approaches overlap; some graphs run locally, and revision-aligned graphs or persistent history are not unique to Kin. This is an architectural comparison, not an exhaustive feature matrix. The redesigned slide contrasts extending existing repository models with Kin making recorded relationships part of repository state and its native change operations. It shows tracked content and recorded connections sharing one repository history. This is the architectural shift proposed by Kin, not a claim that competitors have no graph or that all their context is external to a repository. The statement that added layers are costly and short-term is our company thesis, without comparative total-cost, latency, reliability or long-term superiority evidence in this deck. The closing line, "Superintelligence needs a better foundation," is our ambition for the architecture. It does not assert that Kin is superintelligent, that superintelligence has arrived, or that this benchmark measures its requirements. Official product pages checked October 7, 2026.
Why it lasts. Grouping the six products as code hosts, context engines and agent records is our simplification of their primary approach; several span more than one. "Stays current": Kin's background service re-parses only edited source and re-derives the affected entities and relationships, marks cross-unit links it has not yet rechecked as owed, and reports graph freshness with every answer rather than serving a stale link as current. Branches merge by entity identity against the common base, and a merge that does not compose is kept as a conflict record. "Works beside Git": kin init reads Git history without changing the repository, Git stays the import and export boundary, and kin git export writes a Git repository. Shallow clones, submodules and Git LFS are not yet supported.
Kin Computing, Inc. is pre-revenue and self-funded to date. The plan begins when a seed round closes: Q1, make the first hires; mid-Q1 through mid-Q2, work with design partners; Q2 through Q3, win the first paid teams and improve the product from their feedback; Q4, expand the team's capacity to build and support the product.
The quarters express a planned sequence from our 24-month operating model (refreshed October 8, 2026), not signed pilots or contracted revenue. The first two hires are a repository reliability and performance engineer (month 1) and an agent adoption and developer-experience engineer (month 3); a hosted deployment and customer integration engineer follows in month 10 as paid demand grows. The model plans three design partners, the first in month 2, and paid pilots from month 4. Before the next raise, which the model times for months 15 to 18, we expect to show repeat team use, signed willingness to pay, retention, referenceable teams, measured service cost and a repeatable customer process. Paid teams, design partners and financing are future milestones.
The working target is $3.75 million, set by the founder on October 9, 2026. Valuation and instrument are not set. The four shares are rounded from our 24-month operating model, which assumes no revenue and no cloud credits. Product and engineering covers the first engineers, reliability, security reviews and hosted KinLab. Go-to-market and community covers design partners, developer adoption and paid pilots. Operations covers legal, accounting and insurance. The reserve is a three-month operating reserve plus cash held until results justify spending it. "24 months of runway" is the plan's horizon with that reserve intact, not the point where cash runs out. The operating model is available on request during diligence.
Kin is self-funded to date with no outside equity. The closing line, "Superintelligence needs a better foundation," is our ambition for the architecture, as described under slide 10.