Concept to launch: help the founder decide what deserves building

A customer asks for a feature. Another customer reports a workaround. An agent suggests a new product. These are inputs to a decision, not instructions to start coding. A solo founder needs a way to investigate demand without turning every interesting idea into an unfinished project.

The Concept-to-Launch prototype models ideas, research spikes, hypotheses, business cases, design specifications and build increments. Its strongest contribution is making the investment decision explicit before the workflow advances.

Turn the signal into a falsifiable question

For the studio example, two customers ask for recurring ingestion of updated documents. The question is not “should we add agents?” It is “will customers pay for a maintained document collection, and can it be supported within the proposed service budget?”

A research record can state:

hypothesis: customers will pay for managed document updates
signal_refs: [request-041, request-052]
research_limit:
  founder_hours: 4
  external_spend_sgd: 100
required_evidence:
  - customer willingness to pay
  - representative update frequency
  - failure recovery requirements
stop_condition: no repeatable paid need found

These are example limits. The value is that the research has an exit condition. A capable agent can gather alternatives, compare evidence and draft the business case within that boundary.

The prototype's stage sequence

Idea submitted → research spike approved → research complete
  → hypothesis and draft offering
  → business case approved → design signed off
  → build increment accepted → experiment → launched

The local implementation can walk this sequence with seeded records. It does not independently research a market or build and deploy a product. Its agents and effects demonstrate how preparation and approval can be separated.

An offering cannot commit to its build stage without the linked approved business case. The policy reads the recorded case status rather than relying only on a role label. That is an important distinction: having permission to request a build is not evidence that the business approved this build.

Keep assumptions visible through the build

The approved case should contain expected customer value, cost assumptions, uncertainty, proposed price and the experiment that will test the uncertain part. Those fields should remain linked to the design and implementation work.

For the recurring-ingestion offer, a build packet might specify a sample source, duplicate handling, update detection, maximum processing spend and recovery from a malformed document. An agent can prepare tasks and acceptance checks from that packet. The founder or delivery owner decides whether the resulting evidence is sufficient to advance.

The current prototype marks a build increment through its lifecycle using deterministic effects. Connecting a repository or CI run to the acceptance evidence is the next implementation. A green state alone is not a test report.

Product experiments need a denominator

If three customers use a new capability, I also want to know how many were offered it, what they were asked to do and whether the use produced the intended outcome. A conversion ratio without the cohort and measurement window is difficult to interpret.

The experiment record should distinguish observation from recommendation:

{
  "hypothesis": "customers value maintained document updates",
  "eligible_accounts": 5,
  "accepted_paid_trial": 2,
  "window_days": 14,
  "observed_support_minutes": 90,
  "decision": "founder_review_required"
}

These illustrative values do not automatically justify launch. They help the founder compare the demand signal with the support burden and remaining uncertainty.

Launch creates work in other loops

An approved offering should update campaign claims, the sales package, delivery acceptance criteria and support material together. If marketing announces a capability before delivery can support it, the launch has created a coordination failure.

I would make the launch packet versioned and have each receiving loop acknowledge the version it can operate. Failed acknowledgements become a release blocker or an explicit limited launch, rather than a silent gap.

How a solo founder uses this first

Start with a single idea backlog and a small weekly research budget. Let the agent prepare evidence and identify duplicated requests. Review a short list of hypotheses, approve one bounded spike and record why the others were deferred.

The measure is learning per unit of founder time and spend: which assumption changed, what was stopped, and whether the selected work improved a customer outcome. The platform should make it easier to stop an unsupported idea. Generating more attractive business cases would be a poor substitute for that discipline.

Make a product hypothesis falsifiable

For the studio, an idea might be “maintenance teams will pay for source-linked answers over their manuals.” That is still too broad to allocate a build budget. Narrow it to a customer segment, a repeated task, an alternative they use today, a price assumption and an observable test.

A proposed experiment could ask three relevant operators to complete five real lookup tasks with a reviewed prototype. Record whether they found usable evidence, where they needed help and whether they would commit to a paid pilot at the proposed price. The small sample informs the next decision; it does not establish a general market conversion rate.

from company_lab.business import launch_decision

evidence = {"problem_interview", "delivery_estimate"}
assert launch_decision(evidence, 150000, 200000) == "GATHER_EVIDENCE"
evidence.add("price_test")
assert launch_decision(evidence, 150000, 200000) == "REQUEST_BUILD_APPROVAL"

The reference gate asks for evidence categories, not a favourable conclusion. A price test can be negative. The review packet must retain the result and uncertainty, otherwise an agent can satisfy the checklist by creating three documents that merely repeat the idea.

Separate discovery work from a build commitment

Discovery may involve research, interviews, a throwaway prototype and a delivery estimate. Building a supported product introduces different obligations: operating cost, support, access controls, release process and a customer promise. The platform should make the transition explicit.

I would use an experiment record containing hypothesis, audience, method, spend ceiling, owner, evidence references, observed result and decision. An approved business case points to those experiments. The delivery loop receives a scoped build request only after that decision.

The agent can prepare an evidence table and compare alternatives. It can also identify contradictory signals: users like the prototype, but the requested deployment model costs more than the target price permits. That contradiction is useful founder work, not something the model should smooth over in a positive executive summary.

Choose connectors by the experiment

A research task needs document and web-source capture with provenance. An interview task needs calendar coordination, consented notes and a structured evidence record. A landing-page experiment needs deployment and analytics receipts. A pricing conversation needs the actual proposal and customer response.

Do not connect an advertising account simply because the product loop contains a marketing stage. First decide what observation would change the decision. If the question is whether a workflow solves the user's problem, paid traffic to a generic page may produce activity without answering it.

A code-generating agent can open a prototype pull request against a sandbox repository. Its tool scope should exclude production deployment and live customer data. The release agent receives authority for a specific environment only after the appropriate review. The business loop and engineering harness therefore share artifact identities and decisions without collapsing into one omnipotent builder.

Carry operating costs into the decision

Suppose the prototype requires expensive document parsing for each new customer. The product packet should include cost per onboarding, expected refresh frequency, error review and support effort. The price assumption must be compared with that delivery model before the platform labels the concept attractive.

These estimates should be ranges with their source and sensitivity. A single LLM-generated market-size number is weak evidence. A measured parsing run over representative documents, a stated pricing assumption and a customer interview are different kinds of evidence; the record should preserve that distinction.

Stop experiments deliberately

An experiment can end as proceed, revise, defer or stop. Record why and which evidence would reopen it. Otherwise a scheduled agent can rediscover the same rejected idea every week and produce another business plan.

The exercise for this chapter is a positive usability result paired with a failed price test. The platform should prepare a decision about scope, segment or delivery cost, not automatically launch the build. The agent's useful contribution is making the trade-off concrete enough for the founder to choose.