/ds-productize

Projects reach technical ship-readiness with zero revenue readiness: no monetization model chosen, paid features unenforced, pricing invented in the release week, and no funnel instrumentation to learn from. Skill audits the business layer with the same file:line rigor the rest of the suite applies to code.

Productize — monetization, pricing/packaging, and go-to-market readiness audit + productization plan.

Completion Evidence — applies to every phase: Report done/OK only with the machine-checkable evidence the gates name — the exact command run and its observed output (or file:line diff). Missing evidence → report INCOMPLETE plus what is missing. Self-assessment is never evidence. (This band repeats at file end by design — both copies are normative.)

Triggers

• User runs /ds-productize, or asks to turn a project into a paid product/SaaS, audit monetization/paywall/billing readiness, design pricing tiers or packaging, or check go-to-market readiness — see the table below for concrete phrases

Triggers — INVOKE / DON'T INVOKE

Contract

Dimensions: A1 (GTM), A2, A3 (funnel), A11 (GTM signal)

• Covers three scopes: monetization (model + billing/entitlement integrity), pricing (metric + tiers + packaging + channels + unit economics), gtm (positioning + funnel baseline, including funnel-analytics instrumentation — ops telemetry delegated to ds-deploy).
• Audits and plans — generates findings and ds/productize/plan.md; payment-provider integration code itself is implemented by the user or ds-backend.
• Only recommends established patterns with published benchmarks — no speculative growth hacks.
• Minimal liability + maximum privacy: recommends Merchant-of-Record or managed billing over hand-rolled payment handling; funnel metrics are privacy-first (no PII in events, consent-gated where required).
• Standalone. Uses blueprint profile or ds/audit/findings.md when available; own analysis when absent.
• State-exempt: audit + plan are regenerable from source; the plan file and git are the durable record.
• Full accounting enforced: every finding and planned check ends in an explicit disposition (fixed / skipped + reason / only you can do); summary totals balance.
• Pre-existing / out-of-scope errors detected during work are NOT skipped — fixed inline or escalated with concrete blocker. <!-- portable-only -->

Arguments

Default: no disambiguating flag resolves to --audit (recommended), recorded in the summary. --ask: present the full mode menu — Audit (recommended) — find gaps in monetization/pricing/gtm / Plan — design the productization path from current state / All — audit then plan / (Cancel).

Scopes

Monetization

1. Model fit — chosen model (freemium / hard paywall / subscription / one-time / hybrid) matches product type and cost structure; AI apps with variable per-unit cost use hybrid or usage caps; recommendations default to hybrid (base + metered) over pure usage-based (MON-01 benchmark)
2. Entitlement enforcement — every paid feature checks entitlement server-side; no client-only gating of paid capability
3. Billing integration — managed provider or MoR present; payment webhooks signature-verified; both idempotency layers audited — API-request keys and webhook event dedup are distinct checks (MON-04); no card data touches own servers
4. Subscription lifecycle — trial terms disclosed before purchase, renewal reminders, grace period + dunning for failed payments, restore purchases available
5. Cancellation parity — cancelling takes no more steps than subscribing; no dark patterns (roach motel, confirm-shaming, forced continuity)
6. Free-tier gate design — free tier demonstrates core value but preserves an upgrade reason; no bait-and-switch removal of shipped free features

Pricing

1. Price metric — value metric selected before model/tiers (Stripe 4-property test: flexible with value, self-explanatory, hard to game, budget-aligned); seat-only pricing on agentic-AI products flagged (PLD-01, PLD-03)
2. Tier structure — 2-3 tiers with a marked target tier; decoy/anchor logic intentional, not accidental; public page ≤3-4 plans, ≤2 pricing axes (PLD-02)
3. Price presentation — charm vs round pricing matches positioning; per-day/savings framing on the pricing page; annual discount at segment norm (consumer 30-40%, B2B 15-20% — PRC-02/DSC-02) with savings badge
4. Packaging page — pricing page exists, lists outcomes over features, ≤3 choices, highlighted recommended plan
5. WTP evidence — price traceable to willingness-to-pay input (Van Westendorp for new-to-market, conjoint for established/tiered — WTP-01) and a competitor price map (CPR-01; ds-benchmark present → delegate the scan; absent → inline top-3-5 pricing-page scan)
6. Commission/processor fit — store Small-Business programs claimed where eligible; current commission tables used (Play structure changes 30 Jun 2026 — CHN-02); web checkout processor matches revenue stage (MoR below tax-complexity threshold); sales motion matches ACV band (CHN-01)
7. Price externalization — prices/products defined in provider dashboard or remote config, never hardcoded in client builds
8. Price-change protocol — planned increases carry contract-clause check + notice period + grandfathering sunset (CHG-01/02); discounts under a ceiling with tracked cohorts (DSC-01)
9. Projection sanity — revenue plan anchored to segment-correct benchmarks (NRR, churn by segment, AI-adjusted gross margin, LTV:CAC floor semantics — PRJ-01)

GTM

1. Value proposition — one-paragraph concrete promise exists and matches what the code ships (cross-checked against blueprint spec-alignment when fresh)
2. Persona/JTBD — target user and job-to-be-done stated somewhere durable (README, landing copy, plan)
3. Landing/conversion surface — landing page (or store listing for mobile) with headline, social proof slot, single primary CTA
4. Funnel instrumentation — acquisition→activation→revenue→retention events defined, object-action naming, privacy-first (no PII in properties, consent where required)
5. Revenue metrics baseline — MRR/churn/trial-to-paid measurable from existing data; LTV:CAC computable once ads spend exists
6. Launch plan — pre-launch checklist exists (waitlist/beta, announcement channels, press-kit basics) or is generated into the plan
7. Ecosystem openness (A11, advisory) — webhook emission, standard export formats (ICS/CSV/JSON), embeddable surfaces, public API posture flagged as an anti-lock-in GTM signal when a competitor offers it and this product lacks it; never a blocker; technical implementation is ds-backend's A11 scope

Delegation

Owns: monetization, pricing, gtm, analytics (funnel) | Delegates: ds-compliance → subscription-law + privacy canonical audit; ds-backend → billing data model + webhook endpoint security pass; ds-deploy → analytics (ops telemetry); ds-benchmark → competitor price-map scan (CPR-01, advisory-handoff: absent → inline top-3-5 pricing-page scan); ds-launch → store/IAP listing + release execution; ds-research → pricing/competitor evidence (optional) | Receives: ds-ship → Phase 2 productize pass on paid-product intent

Execution Flow

Setup → Discover → Audit → [Plan] → [Needs-Approval] → Summary

Phase 1: Setup

1. Flags → proceed directly. No flags → interactive menu.
2. Upstream artifacts: Profile → {Type + Stack, Audience:, Deploy:, Data:}. Findings({monetization, pricing, gtm, spec-alignment}) → verify + use. Absent → own analysis.
3. Monetization-intent block — four questions with signal-derived (recommended) defaults: references/monetization-intent.md. Default: apply every recommended default and record each as Decided without asking — say if wrong: {question} = {value}; unknown signal → that question not-stated, never guessed. --ask: ask the block once, only the unknowns.
4. Load references by active scope: references/rules-monetization.md (monetization + pricing surface), references/rules-pricing.md (pricing method, channels, unit economics), references/rules-gtm.md (gtm).

Gate: Mode + scope + intent answers recorded (by signal default or by --ask response). If fails → a signal-derived default is unknown and --ask got no response → mark that intent not-stated, WARN, calibrate findings to "model not yet chosen" instead of guessing one.

Phase 2: Discover

1. Search for billing/provider signals: payment SDK deps, webhook routes, product/price identifiers, paywall components, entitlement checks.
2. Search for pricing surfaces: pricing page routes/files, store product metadata, price literals in source.
3. Search for GTM surfaces: landing page, analytics/event calls, funnel definitions, launch docs.
4. Build inventory per scope: present / partial / absent, each with file:line evidence.

Gate: Inventory lists every active scope as present / partial / absent, with file:line evidence for each detected surface. If fails → a scope has zero detectable surface → mark scope greenfield (audit reports gaps as design targets, not violations), continue.

Phase 3: Audit [--audit or default]

1. Evaluate every scope checklist item (Scopes section) against the inventory — each check yields finding / pass / N/A with reason.
2. Severity per the Severity table; benchmarks and thresholds from the loaded references. Security baseline on billing surfaces: validate at every boundary, least privilege on provider credentials, no secrets in source; config discipline: prices/product IDs externalized to provider config, never hardcoded (../core/principles.md §5, §8).
3. Classify: A — code-level conformance to the already-chosen model (unverified webhook signature, client-only entitlement check, hardcoded price literal). B — model, tier, price, packaging, or promise changes (business decisions).
4. Cross-check value proposition against blueprint spec-alignment findings when fresh — a promised-not-implemented paid feature is CRITICAL here (selling what doesn't exist).
5. Write findings to ds/audit/findings.md (scoped overwrite: monetization, pricing, gtm). --preview: print the findings table in chat instead; write nothing.

Gate: Every checklist item has an outcome; findings written (per audited scope: grep -c '{scope}' ds/audit/findings.md → >0), or printed in chat under --preview. If fails → un-evaluable check (e.g., store metadata unreadable) → record N/A (unreadable: {reason}), never silently skip.

Phase 4: Plan [--plan or All]

1. Generate the plan — chosen/recommended model with rationale + benchmark, tier table with prices and gates, billing-provider decision path, GTM checklist (landing, funnel events, launch steps), open business decisions as an explicit decision table. Default: write/overwrite ds/productize/plan.md. --preview: print the same plan in chat; write nothing.
2. Every recommendation cites a rule ID from references or an inventory fact — no unsourced business advice. KISS/YAGNI (../core/principles.md §6): recommend the simplest stack that fits the stated revenue stage — no enterprise billing machinery, custom receipt servers, or multi-tier entitlement services pre-revenue.
3. Present the plan's decision table to the user; record chosen options in the plan file.

Gate: Plan produced (file written, or printed in chat under --preview) with decision table present. If fails → write unresolved decisions as OPEN — needs owner decision rows; plan ships with open rows rather than invented answers.

Phase 5: Needs-Approval Review [needs_approval > 0]

Default: every item resolves by best judgment (applied, using the same impact/effort/risk reasoning an approval block would show) and the reasoning is recorded in the summary; items matching the publish/irreversible exception list become skipped (only you can do) instead. --ask: state the question (Decide these N items?) and present each item compactly (one line [severity] title — file:line or surface) grouped by scope with counts; ask Apply all / per-scope bulk (Apply all pricing … alongside the total, CRITICAL bulk still confirms per item) / Review Each / Skip All. approve-all excludes CRITICAL; "all" = exactly the displayed set.

Gate: All items resolved. If fails → no response → skipped (no response), proceed.

Phase 6: Summary

ds-productize: {OK|WARN|FAIL} | Scopes: ran {a,b} · N/A — {c}={reason} | Findings: {n} | Fixed: {n} | Skipped: {n} | Only you can do: {n} | Failed: {n} | Total: {n}

Disposition accounting — totals balance. Audit output: findings table grouped by scope. Plan output: ds/productize/plan.md path + open-decision count, or the chat-printed equivalent under --preview.

Effect: 1-5 concrete bullets, real changes only — each states what got better and why it matters, in plain language a non-technical reader understands (quantified when measurable), never the mechanical activity; they are the closing block's Effect line. Example shapes (placeholders, not literal output):

• {n} paid features had client-only gating — entitlements now flagged for server-side enforcement before launch
• Cancellation flow fails parity ({n} steps vs {m} to subscribe) — legal exposure flagged before first paying customer

Zero-change run: No gaps — monetization/pricing/gtm surfaces meet reviewed scope. Preview run: Preview only — {n} findings, plan drafted in chat; re-run without --preview to write ds/audit/findings.md and ds/productize/plan.md.

Gate: Summary + Effect printed; plan path confirmed when Phase 4 ran. If fails → plan unwritten → surface error, print plan content to chat as fallback, status WARN.

Quality Gates

• Every monetization finding cites the file:line or surface (store metadata, provider dashboard item) it was observed on
• Every benchmark claim in findings/plan cites a rule ID from references — no from-memory statistics
• Recommendations never include a provider/package that fails Trust Verification (exists, maintained, fits revenue stage)
• W9: state-exempt — audit + plan regenerable; plan file + git are the durable record. W10: defer to fresh ds/audit/findings.md for covered scopes (esp. spec-alignment); own scan only for uncovered.
• W1: cite file:line or surface, never assume. W2: check consumers after modify. W3: only task-required lines. W4: re-read after gap. W5: uncertain → lower severity. W6: verify all phases output. W7: dedup file:line. W8: no raw shell interpolation. <!-- portable-only -->

Error Recovery

Severity

Edge Cases

Completion Evidence — final gate (duplicate of the opening band by design): Before the summary line, show the evidence for every gate that ran — command plus observed output; a phase with no visible output was not executed — execute it now. Report done/OK only with this evidence present; otherwise report INCOMPLETE plus what is missing. <!-- portable-only -->