Change a price

You want to change what a plan costs. Editing the price is one line; the real question is what happens to subscribers already on the old price. A subscription holds a recurring-price pin that a release never changes silently, and a usage-pricing binding (pricing.current() by default) that follows the live catalog. So a recurring-fee change reaches new subscriptions only, while a catalog-rate change reaches every current() subscriber from activation forward. Moving an existing subscriber to the latest recurring price is a deferred post-launch operation.

Outcome#

New signups receive the new recurring price; existing subscribers keep their pin. Metered rates on current() plans follow the new catalog.

Prerequisites#

• The current plan key and price
• Preview evidence for the new contract
• Billing-owner approval before production publish or migration

Edit the price#

Prices live on fs.plan() in the folder-discovered business/ program. Money constructors accept human major units and lower them to exact integer cents.

import * as fs from "@farthershore/business";

// Raise Pro from $199 to $249 per month. Preserve its existing route refs.
fs.plan("pro", {
  kind: fs.plan.kind.flat,
  price: fs.money.usd(249).monthly(),
  grants: [managedJobs],
  limits: [requests.perMinute(6000)],
});

To change a usage rate instead, edit the catalog the plan binds:

const apiPricing = fs.pricing("api_usage", {
  meter: apiUsage,
  catalog: [fs.rate.per(1000, fs.money.usd(6))], // was $5 per 1,000
});

Build, push, then cut the release. A price change is economic, so the push validates and is accepted but its publish defers to a release — nothing changes for subscribers until you cut one:

farthershore build --format json
farthershore commercial-release diff previous-release.json candidate-release.json --format json
git add business/ && git commit -m "raise Pro to $249" && git push
farthershore apply-timeline list croncloud --format json   # economic → publish: skipped
# After explicit approval of the exact SHA, version, and cohort impact:
approved_sha="$(git rev-parse HEAD)"
git tag -a v2.0.0 "$approved_sha" -m "v2.0.0"
git push origin v2.0.0
gh release create v2.0.0 --verify-tag --target "$approved_sha" --title "v2.0.0" --generate-notes

Replace the example version with the approved next semantic version. An active repo-managed business rejects farthershore business publish, including dry run, with MANAGED_BY_CODE; later releases are GitHub Releases.

The release publishes a new commercial release containing the repriced pro plan. Existing Pro subscribers keep their $199 recurring-price pin. Anyone subscribing after activation pays $249. If the release also changed the api_usage catalog, every subscriber bound to apiPricing.current() is rated at the new rate from activation forward — usage already admitted stays at the old rate.

Existing subscribers#

Moving an existing cohort to the latest commercial release is intentionally deferred until the post-launch migrate-to-latest workflow ships. Do not treat a new release as consent to reprice or re-entitle an existing subscription.

Verify it works#

• farthershore build succeeds and the new price is in the validated plan.
• After publish, a fresh signup is charged the new price.
• Existing subscribers keep their recurring-price pin.
• farthershore commercial-release diff lists pro under changed compiled plans (and a new rating-context version if a catalog changed).

Common failures#

• The amount is off by 100: recurring prices are integer cents.
• The push validates but does not deploy: economic changes wait for a release.
• A subscriber's usage rate did not change: they are on a fixedVersion agreement; amend the agreement.

Recover#

Stop any pending manual migration. Correct the plan in code, validate in preview, and publish a forward release after billing approval. Do not edit Stripe prices or subscriber rows by hand.

Agent prompt#

Change the existing Pro price from $199 to $249 in the business/ program. Build, push to preview, show the semantic diff and production publish dry run, and explain which subscribers the change reaches. Ask before publishing.

Related#

• Add metered routes — change usage pricing, not just the recurring fee.
• Publish a production release — the gates a publish must pass.
• CLI quickstart — use the same build, push, and verification loop.