Build AEG Startup OS for rapid PMF search

[yao23]

Corrected goal

Build an AEG Startup OS for a solo founder searching rapidly and rigorously for product-market fit.

This is broader than automating the AEG experience library. The experience library, repair lab, VS Code extension, website and content are experiment assets inside the startup loop:

Market signal → Riskiest assumption → Falsifiable hypothesis → Smallest experiment → Build → Distribution → Behavioral evidence → Decision → Next hypothesis

Optimize validated market learning per unit of founder time, not commits, experience count, content volume or agent activity.

Company agents

1. Founder/orchestrator — prioritization, capital/time budget, state, conflicts and morning brief.
2. Market intelligence — competitors, ecosystem shifts, public developer pain, substitutes and wedge opportunities.
3. Customer/problem researcher — personas, workflows, pain frequency/severity and interview/feedback synthesis.
4. Experiment strategist — falsifiable hypotheses, preregistered thresholds, cheapest credible tests and kill criteria.
5. Product/Codex builder — extension, repair lab, landing pages, demos, instrumentation and technical experiments.
6. Evaluator/data analyst — causal validity, telemetry, cohort/retention analysis, technical verification and claim audit.
7. Founder-led growth — evidence-backed content, demos, launch packages, CTA and channel experiments.
8. Feedback/CRM — reactions, objections, requests, interview pipeline and next-hypothesis proposals.
9. Fundraising analyst — traction narrative, market map, defensibility, milestones and data room readiness; inactive until evidence warrants it.

Startup hypothesis schema

Each hypothesis must include:

• target persona and job-to-be-done;
• painful/frequent current behavior;
• existing alternative or workaround;
• proposed AEG value;
• riskiest assumption;
• experiment and distribution channel;
• behavioral metric and threshold;
• invalidation/kill criterion;
• time, token and cash budget;
• evidence sources;
• decision: persevere | pivot | stop | more-data;
• learning and next hypothesis.

PMF evidence ladder

Prefer stronger evidence:

1. public comments/likes;
2. interview statements;
3. installation or demo completion;
4. successful activation on a real task;
5. repeat use without prompting;
6. contribution/referral;
7. willingness to pay or design partnership;
8. paid retention and organic pull.

Do not present lower-level signals as PMF.

Initial assumptions to test

1. Problem: coding agents repeatedly rediscover diagnostic/recovery paths, and developers perceive this as costly.
2. Wedge: verified recovery experience is more valuable than generic skill discovery.
3. User: agent-framework, IDE-agent and CI/tooling developers are a better early adopter segment than general developers.
4. Product: an experience recommendation changes agent behavior enough to improve success, cost or speed.
5. Workflow: developers will allow sanitized experience persistence when privacy/provenance controls are explicit.
6. Distribution: transparent public repair experiments and founder-led technical content attract qualified users.
7. Retention: value compounds as later tasks retrieve earlier verified experience.
8. Business model: teams will pay for private experience graphs, evaluation, governance or shared organizational learning.

Experiment portfolio

Maintain a balanced portfolio:

• desirability: interviews, problem posts, waitlist/CTA, concierge experiments;
• product value: baseline versus AEG tasks, activation and repeat-use telemetry;
• distribution: channel/message/CTA experiments;
• trust: privacy, provenance and experience-sharing tests;
• monetization: pricing interviews, paid pilot/design-partner offers;
• defensibility: cross-task transfer, proprietary feedback loops and multi-agent interoperability.

The Public Repair Lab is one product-value experiment, not the company strategy.

Operating cadence

Nightly

Advance at most one reversible startup learning cycle or material checkpoint and produce a founder morning brief.

Weekly

Review:

• hypotheses tested;
• behavioral evidence;
• activation and retention;
• qualified conversations;
• distribution performance;
• build/learning ratio;
• decisions and killed ideas;
• next week's highest-risk assumption.

Monthly

Make a portfolio decision:

• deepen the wedge;
• change persona;
• change product surface;
• change distribution;
• test monetization;
• pause or stop.

Founder morning brief

• highest-risk assumption;
• hypothesis and preregistered threshold;
• work completed;
• evidence versus threshold;
• measured fact vs inference;
• decision;
• product changes;
• growth drafts and CTA;
• feedback themes;
• founder approvals needed;
• time/token/cash cost;
• next experiment.

Human approval gates

Agents may autonomously research, build on branches, test, analyze, draft content and prepare outreach.

Founder approval remains required for:

• publishing or replying on social platforms;
• sending interviews/outreach;
• upstream GitHub interaction;
• merging to main;
• marketplace/production releases;
• spending money;
• pricing commitments or contracts;
• investor outreach;
• permission or credential expansion.

First 30-day milestone

Do not aim for “more AEG features.” Aim to answer:

• Who experiences this problem most acutely?
• How often and how expensively?
• Does AEG change behavior/outcomes on real tasks?
• Will users return, contribute data or pay?
• Which distribution message attracts qualified builders?

Target evidence:

• 15–20 qualified problem conversations or equivalent detailed feedback;
• 3–5 external developers completing an AEG-assisted workflow;
• at least 2 returning for another task;
• one measurable AEG improvement across multiple task families, or a clear falsification;
• one design-partner or willingness-to-pay signal;
• documented reasons from users who reject the idea.

Repository deliverables

• startup/hypotheses.json
• startup/experiments/<id>/plan.json
• startup/evidence/events.jsonl
• startup/metrics/scorecard.json
• startup/feedback/feedback.json
• startup/growth/drafts/
• startup/reports/YYYY-MM-DD.md
• project-scoped agents and a resumable orchestrator
• schemas, tests, budgets and approval gates

Success condition

The system is successful when it shortens the path from an uncertain market assumption to credible behavioral evidence and a clear founder decision—not when it merely produces more code, experiences or marketing content.

[yao23]

First bounded Startup OS experiment is preregistered in #8. It tests external developer behavior—not another benchmark: after 25 qualified exposures, the primary threshold is 3 distinct developers actually using an AEG recovery capsule on a licensed public failure. Recruitment remains unlaunched pending founder approval. Draft PR #6’s mixed and negative evidence is included without changing the success criteria.

[yao23]

Second bounded Startup OS checkpoint: S001 launch friction is addressed in Draft PR #10, which adds a one-minute GitHub Issue Form for the no-install concierge test. Issue #8 was updated before launch to use observable qualified targeted invitations instead of public impressions, remove unobservable capsule-open events, record that v0.1.3 PR #6 is merged, and preserve the original 3-user / 2-evidence / 1-repeat thresholds. Further synthetic/model-heavy benchmark runs remain paused; next compute should be spent only on participant-submitted public tasks.

[yao23]

Startup OS checkpoint — D001 preregistered (2026-08-06)

Strategy pivot: test AEG by dogfooding one real project task before scaling a seven-category internal flywheel.

• Created D001: Can AEG improve its next real project task? #12 with frozen baseline / generic-advice / AEG-assisted controls, mechanism evidence, leakage controls, success gates, and a hard budget.
• Paused S001 (S001: Will developers use AEG on one real public failure? #8) before launch; no participant data was collected and its external-adoption thresholds remain unchanged.
• Repository audit found no pushed seven-category project folder or new dogfood execution branch yet. Existing experiences/work-queue/ covers three repair categories and prior runs; it is not evidence that the new seven-category loop has started.
• PR Improve verified-experience retrieval correctness and abstention UX #11 merged retrieval correctness and abstention improvements, but it does not demonstrate that AEG improved the work that produced it.
• Internal dogfooding is capped at three nights or six target trials. Continue scaling only after wins on at least 2/3 targets, including one cross-repository win; then return to external behavior validation.

Current D001 result: 0 runs / need more data. No PMF or generalized efficacy claim is supportable.