First Dollar

Get to the first paying customer in the smallest number of moves. Not a business plan — a money plan. The default failure mode for a skilled builder is to keep building and never charge. This skill refuses to let that happen: it forces a buyer signal before any further building.

The core bet: the first dollar is mostly a validation event. One stranger paying — or one existing user upgrading — is worth more than a hundred "looks cool" comments. Everything here optimizes for reaching that signal fast and cheap, then turning it into something repeatable.

Step 1: Lock the target and read existing demand

If $ARGUMENTS names a project or idea, start there. Otherwise ask which one. Before asking the user anything, look for demand that already exists — for a repo or live product, that's stars, forks, issues, feature requests, support questions, and inbound DMs. Those are stronger evidence than a cold pre-sell. If a repo path is given, offer to read it instead of interrogating.

Then ask, in ONE batch, only what you can't infer (max 4):

1. What exists today — working build, half-build, or just an idea.
2. Who feels the pain, and who pays — the narrowest group with the problem, AND the economic buyer (the person/role who controls the budget; for a dev tool the user and the payer are often different — individual vs team vs company vs sponsor).
3. What they do today instead — the current workaround (a tool, a spreadsheet, a freelancer, suffering, a free OSS alternative). This is the real competitor.
4. Constraints — how fast they need the first dollar, time/money they'll spend, and their country (it affects payment rails and tax — see Step 5).

If the user says "just run it," proceed with stated assumptions.

Step 2: Pick the revenue route, then the smallest sellable slice

Don't default to "build a SaaS and charge subscriptions." Match the route to what exists. Common first-revenue routes, cheapest first:

• Pre-sell / one-time purchase — sell the result before/while building it. Best for a clear deliverable.
• Paid support / consulting — charge for your time around a thing that already exists. Zero product infra; fastest possible first dollar.
• Sponsorship (GitHub Sponsors, etc.) — for OSS with users; low friction, low/variable yield.
• Hosted / managed version — charge to run the open thing for people who won't self-host.
• Dual license / commercial license — keep it open for individuals, charge companies for commercial use.
• Paid add-on / template / integration — sell a premium piece on top of a free core.

Pick the one route with the shortest path to a real payment given what exists, and name why the others are deferred. Rights check for license/hosted/dual-license routes: confirm the user can actually grant the terms they'd sell — who owns the code (solo vs outside contributors), what the current license permits, and what stays free. If they can't grant the rights, don't sell that route. Then carve the smallest slice someone would pay for this week and cut everything else from the v1 offer (it stays in the codebase, just out of the offer). A slice is sellable when it solves ONE painful problem end-to-end for ONE buyer, fits one sentence they'd repeat, and could be delivered by hand (concierge) if the automation isn't ready.

Reject scope creep openly: every "but it also needs X" becomes a post-first-dollar line item, not a reason to delay the sale.

Step 3: Pre-sell BEFORE building more (with honest terms)

The most important step and the one builders skip. Before writing more code, collect a real buyer signal. In order of strength: cash (payment/pre-order link) > commitment (waitlist with a card, or "yes, invoice me") > stated intent in writing (weakest — treat with suspicion).

Produce the exact pre-sell asset: a 5-line offer (headline, who it's for, the result, the price, the call to action). If the product isn't fully built, say so honestly and include plain terms a buyer can trust: what they get, when they get it, and the refund/guarantee. Pre-selling vaporware without a clear delivery date and refund path is how a solo builder burns their name — don't. Never pre-sell something you can't realistically deliver, and don't make regulated or high-stakes claims (health, finance, legal, safety) without qualified review.

If nobody bites here, that's the cheapest failure available. Go to Step 6's diagnosis — don't build past a dead signal.

Step 4: Price it (don't underprice — but fit the segment)

Engineers systematically underprice. Anchor against the buyer's current workaround cost, not "what feels fair." But don't blanket-apply one model — the right shape depends on the buyer:

• Give three numbers: floor (below this it's not worth your time), anchor (recommended, justified by the workaround it replaces), stretch (the high-intent segment / premium tier).
• Choose the model that fits the buyer and minimizes solo support burden — one-time, flat monthly, usage-based, seats, or a sponsor tier. A free tier, trial, or annual plan is fine if the segment expects it; just don't give away the thing that creates the willingness to pay.

State the one recommended price and model and why. Flag where you're guessing.

Step 5: Pick the fastest payment rail (with the honest caveat)

Minimum infrastructure wins. Match the rail to the product:

• One-time digital product / template / asset → Gumroad or Lemon Squeezy (they act as Merchant of Record, which can simplify sales-tax/VAT handling).
• Subscription → Stripe Payment Links or Lemon Squeezy. Don't build auth/billing before paying users — a payment link + manual access grant is fine for the first ten customers.
• Service / done-for-you / consulting → a Stripe invoice. No product infra at all.
• OSS → GitHub Sponsors for donations; a license/hosted offer for real revenue.

Caveat the skill must state, not assume: Merchant-of-Record platforms can simplify sales-tax/VAT but do not remove income tax, business registration, chargeback/refund law, consumer-protection rules, or platform eligibility — and which platforms are available depends on the user's country and product type, and terms change. This is operational guidance, not legal or tax advice — tell the user to confirm their obligations locally before scaling past the first sales. Reject any rail that requires building billing infrastructure before the first sale.

Step 6: After the signal — and when there's no signal

If someone pays: don't celebrate and disappear. Fulfil it (deliver, grant access, be reachable for support), then learn from it — ask the buyer why they bought, in their words; request a one-line testimonial; note who else looks like them (lookalikes for distribution); confirm or nudge the price. Then resist overbuilding — repeat the move that produced the dollar before adding features.

If nobody bites, don't just "reshape" vaguely. Diagnose which link broke:

Step 7: Output the revenue plan

Deliver this, skimmable:

## FIRST-DOLLAR PLAN: <project>

**Revenue route:** <pre-sell / paid support / sponsors / hosted / license / add-on> — <why; others deferred because…>
**The sellable slice:** <one sentence the buyer would repeat>
**The buyer:** <narrowest group> · pays via: <economic buyer> · replacing: <current workaround>
**Existing demand signal:** <stars/issues/inbound, or "none yet — cold start">

**Price:** floor $X · anchor $Y · stretch $Z — justified by <workaround cost>; model: <one-time/sub/usage/sponsor>
**Payment rail:** <Gumroad / Lemon Squeezy / Stripe link / invoice / Sponsors> — <why>  (confirm tax/refund for <country>)

**The pre-sell offer (paste-ready):**
> <headline> / <who it's for> / <the result> / <price + delivery date + refund terms> / <call to action / link>

**Validation gate:** <the exact buyer signal that says "build more">
  → if no signal in <timeframe>: <which diagnosis row applies, and the one change to make>

**Money handoff (the concrete way you get paid AND deliver):** <per route — pre-sell: link; support: booking/contact link; hosted/manual: how access is granted; license: license file + invoice; sponsor: tier + benefit>

**This week's moves (in order):**
1. <smallest first action>  2. …  3. <THE action that lets a real human pay you today — create the link/invoice/sponsor tier now, even if delivery is manual>

**What to NOT build yet:** <scope explicitly deferred>

The plan is not done until move 3 is a live way to take money. End with one line: the single riskiest assumption and the cheapest way to find out if it's wrong.

Rules

• Buyer signal before building. Never green-light more construction without a paying or paid-intent signal — that's the whole point.
• Use demand that already exists (repo issues, stars, inbound) before manufacturing a cold pre-sell.
• Anchor price to the workaround, not feelings — but fit the model to the segment instead of imposing one.
• Least infrastructure that takes money. A payment link beats a billing system; concierge delivery beats automation until volume forces the change.
• Honest pre-sell terms. Delivery date + refund path always; never pre-sell vaporware silently.
• Not legal/tax advice. Caveat jurisdiction-dependent claims; tell the user to confirm locally. Only sell license/hosted terms the user can actually grant, and never pre-sell what can't be delivered.
• Match the user's voice and risk tolerance — don't impose a tone or a pricing dogma.
• Pairs with /roast (validate the idea first) and /distribution (get the offer in front of buyers). Hand off in one clean move — if the idea is unvalidated, suggest /roast; once there's a price and a link, suggest /distribution. Don't ping-pong.