Pricing optimizer
Skill hamza-ali-shahjahan/hamzaish/factory/agents/scale/pricing-optimizer
Your Claude Code setup that builds, launches, and learns — across the whole product lifecycle. Point Claude Code at this and it runs your whole startup factory — and gets smarter every session. Works with Cursor, Codex & Windsurf too.
npx -y skills add hamza-ali-shahjahan/hamzaish --skill pricing-optimizerAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Iterate pricing post-PMF based on real data — willingness to pay, expansion revenue, packaging tweaks, annual upsell, enterprise pricing.
SKILL.md
3.4 KB, as published. Nobody here has run it
Pricing Optimizer
When you activate
- Quarterly pricing review
- User asks: "should we raise prices?", "test pricing for X", "design enterprise tier"
- After significant feature additions
What you produce
Saved to products/<name>/scale/pricing-review-YYYY-QN.md:
## Pricing Review — <product> — <quarter>
### Current state
- Tiers + prices: <list>
- ARPU: $<X>
- % on annual: <Y>%
- Median time-to-paid: <Z days>
- Churn rate (by tier): <list>
### Signals from the last quarter
- Conversion rate at current price: <%>
- Customer comments mentioning "too expensive": <count>
- Customer comments mentioning "great value" / "would pay more": <count>
- Tier 1 → Tier 2 upgrade rate: <%>
- Cancellation reasons by tier: <breakdown>
### Recommendations
1. <change> — rationale + expected impact
2. ...
3. ...
### Tests to run
- A/B price test: <current> vs <new> — at <signup point> for <segment> — duration <14d>
- Hypothesis: <what we expect to see>
- Stop conditions: <when to call it>
### Enterprise tier (if relevant)
- Triggers: SSO request, > N seats, custom data residency, > $X MRR potential
- Pricing: not on site — "talk to us" with anchor of $<X>/mo
- Process: discovery call → custom quote → SOW → signed → onboarding
### Annual upsell
- Current annual % : <Y>%
- Target: > 40% on annual
- Tactics: better discount, prominent on pricing page, in-app prompts at month 3
Protocol
- Pull data from Stripe + PostHog.
- Look for: pricing-related qualitative signals in support tickets / surveys / sales calls.
- Identify the one pricing change with highest expected value and lowest risk. Test it. Don't change everything at once.
- For enterprise pricing: don't publish a price. Make it custom.
- Annual upsell is usually the easiest pricing win — cash up front + reduces churn.
Contract (handoff)
Per factory/playbooks/mvp-stage/agent-handoff-contracts.md:
- Preconditions (from pricing-strategist):
launch/pricing.mdexists, and ≥1 quarter of the signals it named for logging (conversion by tier, "too expensive"/"would pay more" mentions, upgrade rate, churn by tier) is actually available from Stripe/PostHog. - On precondition gap: no signal data → limit output to an instrumentation plan (which events/queries to wire so next quarter's review is possible); never recommend a price change on gut — that's the strategist's launch-time job, already done.
- Produces:
products/<name>/scale/pricing-review-YYYY-QN.mdin the format above. - Shape: guaranteed sections — Current state / Signals / Recommendations (max 1 change) / Tests to run (with hypothesis + stop conditions) / Enterprise tier.
- Postconditions: exactly one recommended change, tied to a named signal, with grandfathering for existing customers stated explicitly.
Sources
factory/playbooks/launch-stage/pricing-playbook.mdfactory/playbooks/scale-stage/100-to-1000-customers.md
What you don't do
- Don't lower prices to compete. Lower prices → lower-value customers → higher churn → worse unit economics.
- Don't change prices for existing customers without explicit communication and grandfathering options.
- Don't add tiers — pricing pages should get simpler over time, not more complex.