Pricing, cost of delivery, unit economics, business model, offer design¶
All figures produced by this skill are DRAFT until operator approval. The corpus rule is explicit: do not publish pricing without operator approval. Label every number.
Business model (separate from the product)¶
Ask: who pays whom, for what, when, and why?
Models: subscription, transaction, licensing, marketplace take-rate, advertising, sponsorship,
services, support, open-core, hosted open source, enterprise edition, usage-based, data, freemium,
hybrid. Bluefly's current motion is recurring operational responsibility: the customer pays for an
agreed operational scope, priced around the responsibility assumed rather than agents or hours
(bluefly-commercial-doctrine.md). A definition proposing seats, agent counts or hourly billing as
the primary model must explain why the current model does not apply.
Pricing basis¶
Per user, per seat, per organization, per site or environment, per transaction, consumption, storage, API calls or tokens, percentage of value, flat subscription, license, per project, per outcome, freemium, open core.
Choose the basis that tracks the customer's value and is easy for procurement to explain. For public sector, per-site or per-environment flat pricing is easier to buy than metered usage. Metered usage is honest for AI COGS but needs a cap or the buyer cannot budget.
Pricing strategy¶
Cost-plus, competitor anchored, value-based, penetration, premium, land-and-expand.
Price should primarily reflect customer value, not production cost. Cost still determines whether the business is viable. Price also communicates positioning: a $49 add-on and a $24,000 enterprise tier are different products in the buyer's mind even if the code is shared.
Cost of delivery (the part AI products get wrong)¶
Model explicitly: infrastructure, model and API usage, storage, bandwidth, support, implementation labor, customer success, payment processing, third-party licenses, compliance and audit, onboarding, professional services, observability.
For AI products usage can make COGS scale with success. A customer who loves the product can be the one who destroys the margin. Therefore: meter internally even when you price flat; set fair-use caps; prefer smaller models for routine agent work; and put "compute and model cost per accepted outcome" on the metrics list, as the AMCS doctrine already does.
Unit economics¶
REVENUE
- COGS
= GROSS PROFIT (GROSS MARGIN = gross profit / revenue)
GROSS PROFIT
- OPERATING EXPENSES
= OPERATING PROFIT
Track: CAC, LTV, ARPU or ARPA, churn, retention, payback period, contribution margin. LTV must materially exceed CAC. Do not apply generic SaaS benchmarks (3x LTV:CAC, 12-month payback) blindly; a services-led motion with a design partner has different math than a self-serve SaaS. State the assumptions and show the sensitivity to the two or three that matter.
Revenue without margin may be a liability. A pack sold at $49 per month with $60 of model spend is a marketing expense, not a product.
The scaling constraint is usually human review, not compute¶
For any product where a machine prepares work and a person approves it, model cost is rarely what caps growth. Qualified human review is. Measure it in the first pilots:
X = accepted reviews one qualified senior can perform per day
Y = reviewable changes generated per customer estate per month
ESTATES PER REVIEWER ~ (X * WORKING DAYS PER MONTH) / Y
Two consequences. First, an Assist-mode product that generates more review than it removes has
inverted its own value proposition and the margin collapses quietly, one estate at a time.
Second, the way out is not a bigger model, it is moving proven remediation classes up the
authority ladder so they stop generating review at all (mvp-validation.md). Review load per
estate falling over time is the leading indicator that the economics work; if it is flat after
several estates, the product is a staffing business with better tooling.
Put X and Y on the pilot measurement list explicitly. They are usually the two numbers nobody collected and everybody needed.
No free pilots¶
A pilot the customer does not pay for tests nothing. It measures curiosity, not demand, and payment is several rungs higher on the evidence ladder than enthusiasm. A paid bounded pilot also produces the cost data the business model depends on, because the delivery is real.
Price discovery happens through real scoped opportunities, not a predeclared price card built from theoretical ranges. Publishing an unvalidated price card before the first pilots anchors the market to a number nobody has tested and makes it awkward to correct. Authorize discovery, then set the card from what customers actually paid.
Offer design (offers sell products)¶
A product might be: Drupal Launch Factory. An offer is: launch two governed Drupal 11 sites from one foundation in 60 days, including migration, hosting setup, accessibility validation, evidence bundle, and 90 days of operate support, for a fixed fee, with a defined acceptance test.
Every offer names: product, package, pricing, guarantee or acceptance criteria, terms, bonus or services, onboarding, risk reversal, proof. Write the offer before the pricing page; the page is a projection of the offer.
Existing Bluefly pricing artifacts (all DRAFT, all superseded or caveated)¶
products/AMCS/amcs-factory/amcs-starter-kit-pricing.md: Starter, Agency, Enterprise annual tiers with add-ons and a revenue model table; banner says superseded and draft.Engineering-Standard/architecture/gascity/blucity-packs-map.md: per-pack monetization matrix.products/AMCS/bluefly-governed-product-factory-gas-city-official-docs-update-2026-08-03.mdsection 18: the commercial unit is a governed modernization outcome with acceptance evidence.products/OSSA/duadp-ossa-feature-roadmap.md: metering layer in the OSSA manifest (spec.pricing, per call, per token, subscription).
Reuse these as inputs. Do not cite their numbers as facts.