Skip to content

Bluefly Technology Reduction — Product Definition

This is the canonical commercial definition. It is the only place the offer is defined. Delivery lives in Delivery-Method.md, customer-facing copy in Sales-Package.md, reusable artifacts in Delivery-Kit.md, all projected from data-model.yaml.

1. Canonical names

Do not introduce further product names.

Slot Canonical value
OFFER_NAME Bluefly Technology Reduction
ENTRY_OFFER Maintenance Review
DELIVERABLE_NAME Deletion Plan
REMOVAL_OFFER Safe Removal
RECURRING_OFFER Maintenance Watch
PUBLIC_HEADLINE Stop maintaining what you no longer need.
PRIMARY_CTA Find out what you can stop maintaining.

CORE_PROMISE — We find custom technology you're still paying to maintain that your existing systems can now replace, prove it can safely go away, and help you remove it.

2. What the customer buys

Three purchases, in order. Each one is independently sellable and each one ends in a decision rather than a document.

# Offer What it answers Ends with
1 Maintenance Review What are we maintaining that we don't need anymore? A Deletion Plan — ranked, with a verdict per item
2 Safe Removal Can this actually go away without breaking the business? Verified removals, each proven before the old thing is deleted
3 Maintenance Watch What can we stop maintaining next quarter, and what are we about to build that we shouldn't? Two short lists, every quarter

What the customer does NOT buy

  • A rewrite.
  • A migration to a new platform.
  • A new software product, dashboard or portal.
  • Developers by the hour.
  • An AI agent deployment.

This matters commercially: the offer is credible precisely because Bluefly is not proposing to build the replacement. The replacement is something the customer already owns and already pays for.

3. How success is measured

The measure is:

WHAT_THE_CUSTOMER_NO_LONGER_HAS_TO_OWN

Primary measures, used as-is:

Measure Unit Why the buyer cares
CUSTOM_SYSTEMS_RETIRED count The thing is gone, not refactored
MAINTENANCE_HOURS_RETURNED hours/year Capacity back to the team
ACCESS_POINTS_CLOSED count Credentials, tokens and service accounts that no longer exist
UPGRADE_TESTING_REMOVED count of items Shorter, cheaper, less frightening upgrades
KEY_PERSON_DEPENDENCIES_REMOVED count Things only one person understood

Calculated only where customer evidence supports it:

Measure Condition
ANNUAL_OWNERSHIP_COST_REMOVED Requires customer-supplied or customer-confirmed hours or cost

Explicitly not measures of success: code produced, developers assigned, tickets completed, AI agents deployed, consulting hours consumed.

The provenance rule

Every customer-facing number is a measure row in data-model.yaml and carries:

source              where the number came from
assumption          'None' only if directly observed
customer_confirmed  YES | NO

These are the measure field names exactly as data-model.yaml defines them. They are lowercase because every artifact references the model's names rather than a prettier variant — a second spelling of a field is how a kit starts drifting from its own model.

Never fabricate savings. A number the customer has not confirmed is presented as unconfirmed, or it is not presented. An impressive invented figure destroys the one thing this offer sells, which is trust in the evidence.

4. The buyer
Economic buyer CIO, VP Engineering, Director of Digital Platforms — someone who owns a maintenance budget and cannot explain it
Technical champion Platform lead or architect who already suspects which things should go, and has not been given time to prove it
Blocker The person who built the custom thing, or the team whose headcount is justified by maintaining it

The blocker is predictable and must be handled by method rather than by persuasion: Safe Removal proves equivalence side by side and requires named customer approval before anything is switched off. Nobody is asked to take the removal on faith.

5. The buying trigger

Nobody buys this because custom code is philosophically bad. They buy it when maintenance becomes dated and unavoidable:

  1. A forced upgrade with a date on it. The platform major version is moving and every customisation has to be retested or rewritten.
  2. An end-of-life deadline. A dependency, runtime or vendor product stops being supported.
  3. A security finding against something nobody owns. Now there is an auditable reason to act.
  4. A key person leaving. The only person who understood it is going.
  5. Visible maintenance cost pressure. The team is fully occupied maintaining and cannot ship.
  6. Custom code growing faster than anyone approved it — increasingly AI-assisted, which raises the rate at which custom surface appears without raising the rate at which anyone decides to own it.

Trigger 6 is why Maintenance Watch exists as a recurring offer rather than a follow-up: reduction without prevention regrows.

6. Why Bluefly

  • Bluefly has no incentive to sell the replacement, because the replacement is something the customer already owns.
  • Bluefly's own engineering standard measures success as net ownership removed. The offer is the practice, not a repackaging.
  • The method's load-bearing step is proving equivalence before deletion, not after. Removal without that proof is just an outage with a business case.

7. Product classification

Thing Classification
Technology Reduction COMMERCIAL_OFFER
Maintenance Review COMMERCIAL_OFFER / entry engagement
Safe Removal SERVICE / remediation engagement
Maintenance Watch RECURRING_COMMERCIAL_OFFER
ContextControl Separate flagship commercial product and control surface
Gas City, Beads, GitLab, Drupal, OSSA, Cedar, MCP Implementation substrate — never customer-facing value proposition

No new software platform is created by this offer. CUSTOM_TECH_REQUIRED_TO_SELL_OFFER=0.

ContextControl may later carry delivery evidence or customer visibility for this offer. It is not required to sell or deliver it, and this definition does not depend on it.

8. Commercial scope — Maintenance Review

Slot Value
CUSTOMER_PROFILE An organisation running a platform estate with accumulated custom extension, facing an upgrade, consolidation or cost review
BUYING_TRIGGER Any trigger in §5, with a date attached
SCOPE_UNIT A bounded estate: one platform family, one business unit, N sites, N applications, or N repositories. Agreed in writing before start.
INCLUDED Discovery, inventory, replacement assessment, verdict per item, ranked Deletion Plan, executive summary, one review session
EXCLUDED Executing removals (that is Safe Removal), building replacements, platform migration, code rewriting, penetration testing, licence negotiation
CUSTOMER_INPUTS Read access to source and configuration; named owners for each system; maintenance and incident history where it exists; access to the platform team for interviews; a named approver
BLUEFLY_INPUTS Review lead plus one engineer; the Delivery Kit; the data model
DELIVERY_PHASES 1 Scope & access · 2 Discovery & inventory · 3 Replacement assessment · 4 Verdicts & ranking · 5 Deletion Plan & readout
TARGET_DURATION Proportional to SCOPE_UNIT; fixed in the engagement letter, not open-ended
ACCEPTANCE A Deletion Plan where every item carries a verdict and a rank, and the customer has made a NOW/NEXT/LATER/KEEP decision on every NOW item
EXPANSION_PATH Approved NOW items become a Safe Removal engagement; completion transitions to Maintenance Watch

Pricing basis

PRICING_NOT_SET — there is no canonical Bluefly pricing authority for this offer, so this file defines the basis and deliberately does not invent numbers.

Offer Pricing basis
Maintenance Review Fixed fee per bounded scope unit. Not hourly. The customer buys a decision, so the price attaches to the decision, not to effort.
Safe Removal Fixed fee per approved removal, banded by removal_difficulty and removal_risk (both are fields on item). Priced after the Review, because the Review is what makes the estimate honest.
Maintenance Watch Recurring fee per quarter per estate, scaled by the same SCOPE_UNIT as the Review.

Deliberately avoided: hourly staffing as the commercial unit. It rewards time spent, which is the opposite of what the offer measures.

Setting actual numbers requires an operator pricing decision and is out of scope for this definition.

9. Kill criteria

State these so the offer can be withdrawn on evidence rather than defended:

  • If Maintenance Reviews consistently find no existing_platform_replacement with replacement_maturity of GA or SUPPORTED, the premise is wrong for that market segment.
  • If customers approve Deletion Plans but will not approve removals, the offer is selling analysis, not reduction — which is the failure mode it was created to avoid.
  • If final_verdict=ROLLED_BACK becomes common, the Safe Removal method is not safe and must be fixed before further sale.