solo-startup · git:20261102.625c7e9 · 2026-11-02 · sha256 035eaece4a0f5e1c

solo-startup git:20261102.625c7e9A

Immutable. This exact content never changes and is served at /api/v1/blob/035eaece4a0f5e1c.

---
name: solo-startup
description: >-
  Use this skill when a solopreneur or solo startup founder needs to choose,
  validate, or operate a business within one person's cash, time, and support
  capacity, including bootstrapped services, products, and AI-assisted businesses.
  Translate customer evidence into a bounded offer and a sustainable operating
  decision. Do not use for an isolated customer interview, financial calculation,
  growth analysis, or calendar triage; route those to the corresponding specialist.
license: MIT
---

# Solo Startup

Own the decision whether a business promise fits one accountable founder's life,
cash, distribution access, and delivery capacity. Produce a bounded next decision,
not a fictional organization chart of AI employees. This is a methodology skill;
it does not operate payment systems, publish offers, or contact prospects.

## When not to use

Use [product-discovery](../product-discovery/SKILL.md) for customer research alone,
[financial-modeling](../financial-modeling/SKILL.md) for a financial model alone,
and [chief-of-staff-methodology](../chief-of-staff-methodology/SKILL.md) for
priorities, commitments, and calendar triage. Use this skill when the trade-off
crosses these boundaries because the same person must sell, deliver, and recover.
Do not claim that combining these routes has demonstrated superior outcomes.

## Load on demand

- For claims about the phenomenon, AI leverage, or exceptional founder stories,
  read [research synthesis](references/research-brief.md) and
  [source records](references/source-records.md). Refresh time-sensitive claims.
- For selecting an offer or handling changed scope, read
  [models and worked decisions](references/models-and-decisions.md).
- For the deliverable, fill [decision record](assets/decision-record.md).
- For testing this skill, read [eval review guide](evals/review-guide.md).

## 1. Establish the founder's operating envelope

Recover known facts first. Ask only for missing facts that could change the next
decision: desired owner income and time freedom, hours actually available,
committed obligations, cash loss limit, runway, existing audience/customer access,
capabilities, and willingness to use contractors or later hire. Mark unknowns.
Do not presume the goal is fundraising, maximal growth, passive income, or staying
alone forever. A solo founder may have employees; a nonemployer may have multiple
owners and contractors. State which definition applies, at what date and stage.

Separate the economic model from the founder's goal:

| Model | Binding solo constraint | First useful evidence |
|---|---|---|
| Bespoke service | Sales plus delivery hours; client concentration | Paid, bounded engagement with actual delivery time |
| Productized service | Scope variation and review burden | Repeat delivery of the same promise at viable cost |
| Software/digital product | Acquisition, retention, support, maintenance | Paid use of the core outcome plus repeat use/renewal evidence |
| Content/education/commerce | Audience access, fulfillment, inventory or updates | Purchases with refunds, fulfillment and platform costs counted |

Lifestyle income and scalable enterprise value are goals, not separate revenue
models. A service can finance product discovery, but services do not automatically
become scalable products. Funding terms can make a viable small business a poor
fit for investor return expectations.

## 2. Find the smallest promise worth testing

Select one reachable customer segment, costly recurring problem, and concrete
outcome. Record current workaround, buyer, budget, urgency, acquisition route,
and why this founder has access or credibility. Route uncertain problem evidence
to product-discovery; return with the evidence, not a claim that discovery ran.

Rank evidence by what it establishes: stated preference < observed workaround <
credible commitment < payment < successful delivery < repeat paid use. This is a
reasoning aid, not a universal scoring scale. A refundable deposit is a liability;
a waitlist is not retained revenue; payment is not proof of retention or margin.
Record source, date, conditions, refunds, and contradictory evidence separately.

Default to a manual paid pilot or smallest deliverable that tests the riskiest
assumption before building a platform. Define scope, exclusions, price hypothesis,
fulfillment and support promise, learning question, budget/time cap, and a dated
proceed/revise/stop criterion before executing. Thresholds are explicit hypotheses
chosen for this business, never universal founder benchmarks. Draft outreach or
sales pages locally unless execution is separately authorized.

## 3. Close cash and capacity together

Route detailed pricing and scenarios to financial-modeling. Retain these checks:

- Separate receipts, recurring revenue, contribution, accounting profit and cash.
  Count acquisition, payment fees, refunds, variable AI/API use, contractor cost,
  support, maintenance and founder review. Do not assume unknown costs are zero.
- Show founder labor both as hours and an explicitly chosen replacement/opportunity
  cost. Do not double-count it in both unit labor and fixed owner compensation.
- Calculate contribution per unit and fixed-cost break-even only when contribution
  is positive. Negative contribution has no finite break-even from selling more
  identical units. An experimental loss needs an explicit learning cap.
- Deduct sales, administration, support, maintenance and contingency from available
  hours before deriving delivery capacity. Compare achievable capacity with the
  units needed for the owner's income goal, not just operating break-even.
- Stress-test delayed collections, refunds/churn, a support surge, loss of the
  biggest customer/channel, and founder absence. Annual prepayment creates future
  delivery obligations; do not call all cash freely spendable profit.

Use [yc-default-alive-calculator](../yc-default-alive-calculator/SKILL.md) when
runway/profitability timing is the decision, with its input assumptions exposed.
Use [yc-weekly-growth-compass](../yc-weekly-growth-compass/SKILL.md) only for a
relevant growth question; its venture benchmarks are not a default success bar.

## 4. Design distribution as work

Choose one initial channel tied to buyer behavior: targeted relationships,
partnerships, a marketplace, search, or an existing audience. Route positioning
and channel design to [go-to-market](../go-to-market/SKILL.md). Reserve founder
hours and cash for acquiring customers. Track qualified conversations to offers,
paid conversions, delivered outcomes and retained customers; distinguish channel
traffic from qualified demand. Include platform fees, audience ownership/export,
and concentration risk. Building in public is optional, not a distribution plan.

## 5. Make the promise survivable

Limit simultaneous offers and work in progress. Set support hours and response
expectations the founder can actually meet for new offers. Existing customer
commitments remain binding until fulfilled or explicitly renegotiated; a new
support notice or bot does not replace already-promised 24/7 coverage. Arrange
coverage, agree a change with affected customers, or stop making new commitments
while resolving the gap. Use repeated support questions to
improve onboarding/product/docs before adding complexity. Define a small absence
plan: billing and domain access recovery, tested backup/export, incident contact,
customer communications draft, and a way to pause sales or gracefully close.
Route recovery design to [resilience-and-recovery](../resilience-and-recovery/SKILL.md)
when needed; do not imply a backup has been tested without evidence.

For automation, first remove unnecessary work, then standardize a repeated task,
then compare buy/contract/automate with manual delivery. Count setup, supervision,
review, failures and ongoing cost. Measure accepted outcomes and founder time over
comparable tasks; number of agents or generated artifacts is not capacity.
Keep human accountability for quality and commitments. Bound automation access,
cost, escalation and recovery; do not let it independently promise refunds,
pricing, legal terms or delivery dates. Route agent evaluation to
[agent-evals-and-observability](../agent-evals-and-observability/SKILL.md).

Outsource a stable, bounded task when the budget and review capacity support it.
Name acceptance criteria, data access, review time and fallback. Recommend hiring,
changing the promise or reducing demand when required; solo is a choice, not a
purity test. Do not treat contractors as invisible free labor.

## 6. Decide and preserve the boundary

Return a one-page decision record: goal/envelope, dated promise, evidence and
uncertainty, economics and capacity, primary bottleneck, specialist handoff,
next capped experiment, and proceed/revise/stop triggers. If a promise changes,
recompute the dependent economics and capacity before recommending expansion.
Use chief-of-staff-methodology for the ongoing review rhythm; review cash,
qualified demand, delivered quality, retained customers, founder hours and risk,
then choose the next bottleneck. Avoid a heavyweight executive dashboard.

Complete when the next decision is inspectable and feasible under stated inputs,
or a specific missing input blocks it. Stop/revise for negative contribution,
unaffordable cash exposure, capacity below commitments, recurring quality failure,
or evidence contradicting the tested assumption. Do not solve these by silently
raising the founder's hours. A viable recommendation can be staying small,
returning to employment, pausing, changing model, outsourcing, hiring or closing.