Bluefly Strategy, Services & Factory¶

Date: September 19, 2026
Purpose: Living strategic document for Bluefly's identity, commercial model, service architecture, Factory positioning, collective model, use cases, and go-to-market direction.

1. Strategic Premise¶

Bluefly should not present itself as:

a staff augmentation shop,
a traditional agency with AI tools,
an AI-agent vendor,
a Gas City reseller,
a collection of unrelated technical products.

The stronger direction is:

Bluefly is a senior-led governed delivery company that takes responsibility for important digital and software outcomes, using reusable agentic operating capability underneath.

The customer buys responsibility and outcomes.

The senior collective provides judgment.

The Factory provides leverage, repeatability, durable work, evidence, and operating discipline.

ContextControl provides the governed human/control surface.

The Collaborative Impact Model explains how expertise is assembled and shared without relying on a traditional full-time staffing pyramid.

2. The Commercial Problem Bluefly Must Solve¶

Bluefly has credibility from experienced people and strong technical work.

That is not the same as having an easy-to-buy offer.

A likely current market problem is:

MARKET HEARS:
"Bluefly has excellent senior people."

BUYER THINKS:
"What exactly do I buy?"

A senior collective is a credibility mechanism.

It is not, by itself, a purchasing unit.

Bluefly needs a small number of outcomes that are:

understandable quickly,
bounded,
measurable,
repeatable,
valuable enough to fund,
improvable through Factory reuse.

3. The Economic Shift¶

Traditional agency model¶

hire people
→ maintain bench
→ sell hours
→ manage utilization
→ grow revenue by adding headcount

Bluefly model¶

trusted senior collective
→ solve valuable hard problems
→ make the method explicit
→ encode reusable portions into the Factory
→ let agents execute repeatable work
→ keep humans on judgment, risk, architecture, and customer decisions
→ sell managed outcomes
→ improve margin through reuse

The important idea:

AI is decoupling labor hours from customer value.

Bluefly should benefit from that rather than defend utilization economics.

4. Service-as-Software — Bluefly Interpretation¶

Traditional SaaS:

"Here is software. Your people use it to do the job."

Traditional services:

"Here are people. Pay for their time doing the job."

Bluefly service-as-software:

"Give us the job. We deliver the governed result."

Bluefly decides the right combination of:

senior specialists,
agents,
automation,
open-source platforms,
repeatable methods,
human approvals.

The customer does not need to buy the internal machinery.

5. The Collective Is Not the Product¶

The collective should not be positioned mainly as:

"Bluefly avoids full-time employee cost."

That may be economically useful, but it is not the strongest story.

The stronger story is:

Bluefly can assemble senior judgment without building the traditional labor pyramid beneath it.

Traditional professional-services leverage:

senior person figures it out
→ junior people repeat it

Potential Bluefly leverage:

senior person figures it out
→ Factory captures the repeatable method
→ agents repeat governed execution
→ senior person handles exceptions and improves the method

This increases the value of senior expertise instead of maximizing senior utilization.

6. The Internal Cultural Shift¶

The collective should hear:

AI is not replacing the collective. It changes what the collective should spend its time doing.

Senior people should increasingly spend time on:

architecture,
product and business judgment,
risk,
exceptions,
customer relationships,
approval,
method design,
review,
improvement.

The Factory should increasingly handle:

repeatable discovery,
inventory,
classification,
coordination,
implementation patterns,
routine validation,
evidence gathering,
state tracking,
handoffs,
monitoring,
low-risk remediation.

Culture statements worth repeating:

Every client engagement should leave Bluefly more capable than it found us.

If we solve the same problem three times manually, ask why it is not Factory capability.

Human judgment is scarce. Repetitive execution is not.

The customer should pay for the responsibility we take, not the number of humans we consume.

Consulting discovers the method. The Factory makes the method reusable.

The model is replaceable. The governed operating system around the work is the durable asset.

7. What the Factory Means Externally¶

Do not lead with Gas City, Beads, Formulas, Packs, or agents.

Lead with:

Bluefly gives organizations a governed way to delegate real work to AI-enabled systems without losing human control, evidence, continuity, or accountability.

A concise explanation:

Bluefly Factory turns disposable AI interactions into governed work: durable ownership, repeatable methods, policy, evidence, recovery, and human acceptance.

The work lifecycle:

objective
→ durable work
→ ownership
→ authorized specialist/agent
→ governed context and tools
→ repeatable method
→ policy boundaries
→ evidence
→ human judgment where required
→ verification
→ durable closeout

8. Audience-Specific Positioning¶

CEO / Business Leader¶

"You do not need another AI pilot. You need a delivery engine that gets more reliable and efficient over time."

Lead with: - operating leverage, - speed, - lower dependence on headcount, - accountability, - outcome ownership.

CIO / CTO¶

"We take agent work out of disposable chat sessions and put it into a governed operating system with ownership, policy, recovery, and proof."

Lead with: - integration, - durable work, - model portability, - policy, - evidence, - recovery.

Agency Owner¶

"Your best people should not solve the same problem from scratch for every client. Let senior people create the method once; let the Factory repeat the governed parts."

Lead with: - margin, - reuse, - productization, - senior-talent leverage, - faster delivery.

Existing Customer¶

Do not sell "AI transformation."

Sell an existing funded pain as a managed responsibility.

Example:

"Instead of paying us to manually inspect your Drupal estate every quarter, we continuously inspect it, prioritize material findings, remediate approved classes, verify the outcome, and escalate what requires senior judgment."

Bluefly Collective¶

"We are changing how professional expertise scales."

9. Primary Use-Case Families¶

Governed Software Delivery¶

request
→ architecture/context
→ implementation
→ tests
→ MR
→ CI
→ review
→ acceptance
→ evidence

Targets: - enterprise software teams, - digital agencies, - Drupal organizations, - regulated software teams.

Drupal Estate Assurance¶

Managed responsibility for: - upgrade readiness, - security posture, - accessibility, - contrib/custom-code health, - component quality, - configuration drift, - release verification, - evidence.

Potential commercial unit: - site / estate / application portfolio.

AI-Ready Drupal Modernization¶

Customer buys a bounded target state:

legacy estate
→ modern Drupal architecture
→ contrib-first cleanup
→ component governance
→ AI/tool readiness
→ testing
→ operational model
→ evidence

This should be milestone/outcome-oriented rather than open-ended staffing.

Accessibility Operations¶

Not a one-time audit.

continuous detection
→ prioritization
→ approved remediation
→ regression testing
→ human review
→ evidence

Strong targets: - government, - higher education, - healthcare, - large enterprises.

Upgrade Readiness¶

continuous compatibility monitoring
→ dependency assessment
→ deprecation detection
→ remediation backlog
→ staged fixes
→ readiness proof

Transforms upgrade emergencies into managed operational readiness.

Security Remediation Operations¶

finding
→ classification
→ dependency context
→ proposed fix
→ policy gate
→ implementation
→ verification
→ evidence

Human judgment remains for security exceptions, destructive actions, and unresolved architecture risk.

Migration Factory¶

inventory
→ classify
→ dependency mapping
→ content/data mapping
→ transform
→ validate
→ exception queue
→ human decision
→ publish
→ evidence

This is highly relevant to large CMS and legacy-modernization programs.

IT / Platform Operations¶

condition detected
→ durable incident
→ diagnosis
→ evidence
→ approved remediation
→ execution
→ verification
→ closeout

The value is not "AI ran a command."

The value is governed diagnosis, action, verification, and traceability.

Knowledge Work That Must Survive the Chat¶

Examples: - RFP / RFQ response, - proposals, - architecture assessments, - vendor evaluation, - due diligence, - technical research, - policy review.

The differentiator: the work survives the model, agent, and session.

Multi-Agent Business Processes¶

Candidate areas: - procurement, - vendor onboarding, - employee onboarding/offboarding, - contract intake, - grants, - claims, - escalation workflows.

The advantage is orchestration plus accountability, not simply model intelligence.

10. Natural Market Entry Points¶

Tier A¶

Government¶

Good fit because of: - documentation, - long-lived systems, - accessibility, - approval chains, - modernization, - Drupal presence.

Higher Education¶

Good fit because of: - large Drupal estates, - decentralized ownership, - accessibility, - many repetitive web operations, - small central teams.

Healthcare¶

Good fit for lower-risk operational and content workflows where evidence, controls, and human approval matter.

Agencies / Integrators¶

Potentially strong because they already understand: - repeated delivery, - margin pressure, - senior talent bottlenecks, - reusable methods.

Tier B¶

insurance,
financial services,
utilities,
associations,
SaaS / enterprise software.

11. Agency-as-Customer Opportunity¶

Other agencies may be customers, not only competitors.

Potential offer:

Bluefly helps agencies convert repeated delivery methods into governed AI-assisted operating capability.

Examples: - accessibility audits, - migrations, - technical discovery, - upgrades, - QA, - security reviews, - content operations.

The agency keeps its client relationship.

Bluefly helps make its delivery model more repeatable and economically efficient.

12. Forum One / NPS Migration as a Strategic Template¶

This engagement is important because it already resembles the target model.

Current engagement shape: - embedded senior leadership, - discovery, - technical architecture, - evidence-based planning, - API mapping, - six-to-eight-week technical planning, - very large ColdFusion-to-Drupal migration, - Acquia target platform, - large page and application inventory.

Do not describe this simply as:

"Bluefly consultants perform discovery."

The stronger pattern is:

Bluefly runs a governed migration-planning factory that converts a large legacy estate into an evidence-backed migration system and executable plan.

Repeatable stages:

estate inventory
→ page/application classification
→ API and dependency mapping
→ content/data model mapping
→ migration pattern identification
→ exception identification
→ risk classification
→ target architecture
→ sequencing
→ validation strategy
→ evidence-backed roadmap

The Factory should perform as much repetitive evidence gathering, classification, comparison, and traceability as possible.

Senior Bluefly people should focus on: - architecture, - disputed mappings, - migration strategy, - sequencing tradeoffs, - risk decisions, - Forum One/NPS alignment, - acceptance.

The value proposition to Forum One is not "more AI."

It is: - faster time to technical certainty, - less discovery heroics, - repeatable evidence, - fewer hidden dependencies, - explicit exceptions, - better migration predictability, - reusable patterns for delivery.

This engagement should become a template for future migration and modernization offers.

13. Offer Architecture — Working Draft¶

Offer A — Governed Drupal Operations¶

Customer buys: - continuous assessment, - approved remediation, - release verification, - evidence, - senior escalation.

Offer B — AI-Ready Drupal Modernization¶

Customer buys: - bounded target-state modernization, - milestone acceptance, - technical evidence.

Offer C — Migration Factory¶

Customer buys: - evidence-backed estate inventory, - migration architecture, - mapping and dependency model, - repeatable migration patterns, - exception/risk queue, - executable roadmap.

Offer D — Governed Agent Operations¶

Customer buys: - one or more important workflows converted into governed agent-operated workflows, - approvals, - policy, - evidence, - recovery, - support.

Offer E — Strategic Senior Intervention¶

For frontier problems not yet productized.

Purpose: - solve the hard problem, - identify reusable method, - convert repeatable parts into Factory capability.

14. Pricing Direction¶

Do not default to: - hourly rate, - FTE count, - agent count, - token usage.

Do not jump blindly to pure success fees either.

Prefer hybrid structures such as:

base fee
+ bounded managed capability
+ measurable scope/output dimension
+ explicit risk/change boundary

Possible pricing dimensions: - applications/sites covered, - workflows governed, - connected systems, - execution volume, - SLA, - policy/evidence requirements, - delivery milestones, - remediation classes.

Hours can remain an internal COGS measure without being the customer-facing value unit.

15. The Business Flywheel¶

strategic client problem
→ senior collective solves it
→ repeatable method identified
→ Factory capability encoded
→ runtime proof
→ packaged managed offer
→ repeated sale
→ improved delivery economics
→ stronger collective + stronger Factory

Consulting is not the failure to become a product company.

It can be the discovery and financing mechanism for reusable governed capability.

16. Strategic Wedge Tests¶

Bluefly does not need to choose a permanent vertical immediately.

Test a few commercial wedges.

Wedge 1 — Drupal Estate Assurance¶

Question: Will organizations pay recurring fees for Bluefly to take responsibility for Drupal operational health?

Wedge 2 — Migration Factory¶

Question: Will large modernization programs pay for evidence-backed migration planning and reusable execution patterns rather than open-ended discovery hours?

Wedge 3 — Agency Delivery Factory¶

Question: Will agencies pay to convert repeated service methods into governed AI-assisted operating capability?

Wedge 4 — AI-Ready Modernization¶

Question: Will customers buy a bounded modern target state instead of staffing a transformation team?

Success criteria: - understood in under 60 seconds, - identifiable budget owner, - clear acceptance, - recurring or repeatable demand, - Factory reuse increases, - delivery economics improve.

17. Strategic Discipline¶

Bluefly should actively reject these failure modes:

building technical capability without a buyer;
confusing an internal primitive with a product;
calling source code "done" without runtime proof;
treating every customer as a bespoke fork;
promising "AI transformation" instead of owning a concrete problem;
assuming value-based pricing without measurable acceptance;
keeping repetitive expert work manual because it is currently billable.

The strategic question for every engagement:

What responsibility is the customer actually buying, and what portion of this work should never need to be solved manually again?

18. Forum One / NPS — Grounded Commercial Evidence¶

The current Google Drive proposal and internal commercial strategy materially strengthen the Migration Factory thesis.

What the actual opportunity supports¶

Forum One is not merely asking Bluefly for generic staff augmentation.

The recorded opportunity supports three distinct commercial motions:

Architecture / Discovery / Migration Factory Design
Fixed-fee professional service.
Current preferred proposal: 8 weeks / $100,000.
Outcome includes technical baseline, target Drupal 11 architecture, reusable migration patterns, API parity strategy, representative proof of concept, validation framework, executable backlog, and Migration Factory operating design.
Embedded Drupal Engineering
T&M / DOI BPA / GSA labor-category aligned.
Important to the partnership, but intentionally secondary to the differentiated Bluefly service model.
The people support the service; the people are not the product.
Migration Factory Activation / Engineering Onboarding
Internal strategy proposes a follow-on or hybrid activation layer.
Current planning hypothesis: 3–4 weeks, $40,000–$60,000 fixed fee, with $50,000 target.
Purpose: operationalize the Factory, onboard long-term engineers, establish first-wave patterns, CI/CD and validation gates, runbooks, escalation paths, and transfer the operating system into Forum One's delivery team.

What Forum One specifically requested¶

Internal strategy records that Forum One: - kept both staffing and discovery/architecture paths open; - invited Bluefly to submit a ROM / mini-SOW after discussion of a six-to-eight-week discovery service; - requested a concise explanation of the Migration Factory for the approximately 800-component / 100,000-page ColdFusion/MSSQL estate.

This is meaningful buying evidence.

The Migration Factory framing is therefore not merely Bluefly inventing a product around an unrelated engagement. It is directly responsive to a problem and explanation the partner requested.

Important strategic correction¶

Do not rewrite the current Forum One proposal from scratch.

It already contains a strong Factory-shaped model:

Discover
→ Classify
→ Map
→ Review
→ Generate
→ Migrate
→ Validate
→ Resolve Exceptions
→ Accept
→ Reuse

It explicitly separates:

DETERMINISTIC AUTOMATION
AGENT-ASSISTED ENGINEERING
HUMAN ENGINEERING DECISIONS

and defines durable evidence-backed migration records and acceptance criteria.

The next work is therefore:

DO NOT INVENT MORE CONCEPT
→ tighten commercial packaging
→ remove staffing-first language where it weakens the story
→ make the customer outcome unmistakable
→ identify reusable Factory capability Bluefly can carry forward
→ define what evidence proves the Factory during the engagement

Strategic significance¶

Forum One / NPS should be treated as:

Bluefly's first live commercial validation of the Migration Factory delivery model.

It is not yet proof that Migration Factory is a repeatable product across the market.

What it can prove is: - the buyer understands the concept; - a prime integrator sees value in it; - fixed-fee discovery can be sold around governed, reusable delivery outcomes; - the Factory can reduce uncertainty and generate reusable implementation assets; - senior collective expertise and agentic execution can operate as one delivery system.

That evidence should feed directly into the broader Bluefly offer architecture.

19. Forum One Expansion Strategy — Land, Operationalize, Execute, Assure¶

The $100,000 / 8-week Discovery & Architecture engagement should be the entry point to a larger delivery relationship, not a standalone assessment.

The commercial sequence¶

PHASE 1 — LAND
Discovery + Architecture + Migration Factory Design
8 weeks / $100K fixed fee

↓ creates the system

PHASE 2 — OPERATIONALIZE
Migration Factory Activation
3–4 weeks / planning hypothesis $40K–$60K fixed fee

↓ turns blueprint into working delivery capability

PHASE 3 — EXECUTE
Migration Waves / Work Packages
fixed-fee or milestone packages by migration family / wave

↓ produces actual migrated estate

PHASE 4 — ASSURE
Architecture + Migration Assurance
recurring monthly or milestone-based governance, validation, exception escalation, and acceptance support

The two requested full-time engineers should sit inside Phase 3, not become the commercial center of gravity.

They are delivery capacity operating within the Bluefly/Forum One migration system.

Phase 1 — Land¶

Forum One buys: - evidence-backed legacy inventory, - target Drupal architecture, - migration families, - reusable patterns, - API parity strategy, - representative proof of concept, - validation framework, - implementation backlog, - Factory operating design.

Success criterion:

Forum One can begin implementation without rediscovering architecture and migration rules during delivery.

Phase 2 — Operationalize¶

Before or alongside broad implementation, Bluefly should offer a short activation package that:

installs/operationalizes approved Factory tooling;
converts discovery outputs into executable migration procedures;
establishes repositories, CI/CD gates, validation, evidence and exception workflows;
onboards Forum One and embedded engineers;
executes the first production migration slice;
produces runbooks and review criteria;
establishes escalation and architecture-review paths.

This converts a report into an operating capability.

Phase 3 — Execute Migration Waves¶

Avoid selling the entire remaining estate as undifferentiated T&M.

Discovery should identify migration families that can become bounded work packages.

Example structure:

Wave / Family
→ defined source population
→ approved mapping pattern
→ transformation rules
→ migration execution
→ validation
→ exception queue
→ acceptance criteria
→ completion evidence

Commercial structures to test: - fixed fee per migration family; - milestone fee per wave; - bounded capacity + outcome package; - T&M only for genuinely unbounded exception classes.

Staff augmentation becomes supporting capacity, not the primary offer.

Phase 4 — Architecture & Migration Assurance¶

Forum One is prime and should remain in control.

Bluefly can retain a senior assurance layer during the larger program:

architecture review;
migration-pattern governance;
exception escalation;
API parity review;
CI/CD and validation governance;
release/readiness reviews;
evidence quality;
Factory improvement;
specialized intervention.

This could be structured as a recurring monthly retainer, defined monthly capacity, or milestone-based assurance package depending on procurement constraints.

The value is continuity of the architecture and delivery system established in Phase 1.

Monday Conversation Objective¶

Do not aggressively upsell four contracts.

The goal is to get Forum One to agree to the delivery model:

"The eight-week engagement establishes the migration system. We would like to design it so the same system naturally carries into implementation: first operationalization, then repeatable migration waves, with our senior team staying available for architecture and exception governance while the embedded engineers execute within those patterns."

Questions to ask Forum One:

If Discovery validates the approach, who owns operationalizing the Factory and first production wave?
Do they expect Bluefly to remain involved in architecture and migration governance during implementation?
Can subsequent migration waves be subcontracted as defined work packages or milestones rather than only LCAT hours?
Can fixed-fee work packages coexist with the DOI BPA / task-order structure?
Which parts of the estate does Forum One already expect to need specialist support for?
Who will own migration acceptance, API parity, and exception resolution during implementation?
What does Forum One want transferred to its team versus retained as a Bluefly-managed capability?

Expansion Principle¶

Do not manufacture dependency on Bluefly.

The Factory should be transferable and operable by Forum One.

Bluefly earns expansion because it: - knows the architecture; - created the reusable patterns; - can operate and improve the system efficiently; - supplies senior judgment for exceptions; - can take responsibility for bounded migration outcomes.

That is a stronger long-term position than making Bluefly indispensable through proprietary lock-in.

Core Commercial Framing¶

The people support the migration system. The migration system creates the repeatable delivery model. Bluefly remains valuable because it can operate, extend, govern, and improve that system faster than repeatedly starting from scratch.

20. Bluefly Change Management — Making the Strategy Operational¶

The strategy only matters if it changes behavior.

The transformation should therefore be managed as an operating-system change across five areas:

NARRATIVE
→ SALES
→ DELIVERY
→ FACTORY REUSE
→ MANAGEMENT & METRICS

The goal is not to ask everyone to "use more AI."

The goal is to change how Bluefly defines work, sells work, executes work, captures reusable knowledge, and measures success.

20.1 The Core Internal Narrative¶

Bluefly should communicate one consistent idea:

We are changing how senior expertise scales.

The collective remains central.

The change is that repeated execution should increasingly be handled by reusable governed capability rather than repeatedly consuming senior human hours.

Use:

Senior people invent, decide, review, and improve.
The Factory repeats the governed parts.

And:

Every engagement should leave Bluefly more capable than it found us.

And:

The first time we solve something, it is consulting.
The second time, it should become a pattern.
The third time, it should become a capability.

This is a cultural heuristic, not a mechanical rule.

20.2 What Changes in Sales¶

Every opportunity should be classified before proposal creation.

A. Defined Offer¶

A known, repeatable problem with a standard delivery shape.

Examples: - Migration Factory - Drupal Estate Assurance - AI-Ready Modernization - Governed Delivery Factory

B. Strategic Intervention¶

A valuable problem requiring senior expertise but not yet productized.

The engagement must still answer:

WHAT responsibility is the customer buying?
WHAT can become reusable?
WHAT proof can we retain?
WHAT could become a defined offer later?

C. Capacity / Staff Augmentation¶

Allowed when strategically useful, but not allowed to become Bluefly's identity.

Capacity work should be attached to a larger outcome whenever possible.

Example:

BAD:
Two Drupal engineers for six months.

BETTER:
Two embedded engineers operating within the Migration Factory delivery model,
with Bluefly retaining architecture, validation, and exception governance.

20.3 Proposal Gate¶

Before a proposal goes out, answer:

BUYER=
PROBLEM=
BOUNDED_OUTCOME=
ACCEPTANCE=
REUSABLE_METHOD=
HUMAN_JUDGMENT_REQUIRED=
FACTORY_ROLE=
EXPANSION_PATH=
COMMERCIAL_MODEL=
PROOF_WE_CAN_REUSE=

If these are unclear, the engagement is probably still being sold as labor.

20.4 What Changes in Delivery¶

At project kickoff, define two parallel backlogs:

Customer Outcome Backlog¶

Everything required to fulfill the customer's commitment.

Reuse Backlog¶

Methods, patterns, tooling, evidence structures, templates, formulas, packs, runbooks, checks, and lessons that should survive the engagement.

The Reuse Backlog must never compromise the customer's delivery.

It exists to prevent valuable learning from disappearing at project close.

20.5 Engagement Reuse Review¶

Every significant engagement should have recurring reuse reviews.

Suggested cadence: - kickoff, - midpoint, - pre-closeout.

Questions:

WHAT are we repeatedly doing manually?
WHAT decisions require senior judgment?
WHAT steps are deterministic?
WHAT can agents safely assist with?
WHAT evidence do we repeatedly collect?
WHAT exceptions recur?
WHAT would make the next engagement faster?
WHAT should become Factory capability?
WHAT should remain explicitly human?

20.6 Engagement Closeout Must Produce Four Assets¶

Every meaningful project should close with:

1. Customer Outcome Receipt¶

What Bluefly committed to and what was accepted.

2. Reusable Delivery Asset¶

Pattern, method, validation framework, runbook, Pack, Formula, checklist, architecture pattern, or other reusable capability.

3. Commercial Proof Card¶

A short reusable sales artifact:

CUSTOMER TYPE=
PROBLEM=
SCALE=
BLUEFLY RESPONSIBILITY=
METHOD=
EVIDENCE=
OUTCOME=
REUSABLE CAPABILITY CREATED=

Sensitive customer information must be removed or approved before external use.

4. Expansion Map¶

What responsibility naturally follows from the completed engagement?

Examples: - discovery → activation - activation → migration waves - modernization → managed operations - audit → continuous assurance - architecture → implementation assurance

20.7 Commercial Proof Registry¶

Bluefly should maintain a lightweight internal proof registry.

Every proof should identify:

CLAIM=
CUSTOMER TYPE=
PROBLEM CLASS=
PROVEN / PARTIAL / ASPIRATIONAL=
EVIDENCE SOURCE=
REUSABLE IN SALES?=
APPROVAL / CONFIDENTIALITY LIMITS=
RELATED OFFER=

This prevents sales from relying on vague reputation or overstating Factory maturity.

20.8 Offer Registry¶

Keep a small governed offer catalog.

Each offer needs:

NAME=
CUSTOMER=
BUYING_TRIGGER=
RESPONSIBILITY=
INPUTS=
DELIVERABLE / OUTCOME=
ACCEPTANCE=
TYPICAL_PHASES=
HUMAN_ROLE=
FACTORY_ROLE=
PRICING_BASIS=
COGS_DRIVERS=
EXPANSION_PATH=
PROOF=
STATUS=
OWNER=

Status should distinguish:

EXPERIMENT
PROVEN_ONCE
REPEATABLE
MANAGED_OFFER
RETIRED

Do not let the catalog become a list of every technical capability Bluefly owns.

20.9 Leadership Operating Rhythm¶

Weekly — Pipeline / Offer Review¶

Review opportunities by: - defined offer, - strategic intervention, - staff augmentation, - potential reuse, - expansion path.

Biweekly — Factory Reuse Review¶

Review: - repeated manual work, - candidate reusable capabilities, - Factory improvements, - whether capabilities are proven in runtime or still source-only.

Monthly — Commercial Model Review¶

Track: - defined-offer revenue, - generic T&M revenue, - recurring revenue, - repeat engagements, - reuse rate, - gross margin by delivery shape, - senior human effort by judgment vs repetitive execution.

Quarterly — Portfolio Review¶

Decide: - which offers graduate, - which die, - which remain experiments, - which strategic interventions generated reusable methods, - whether Bluefly is actually becoming less dependent on headcount growth.

20.10 Metrics That Matter¶

Do not over-engineer measurement initially.

Start with:

Revenue Mix¶

% defined-offer revenue
% managed/recurring revenue
% generic T&M / staff augmentation

Reuse¶

% engagements using existing reusable capability
# new reusable capabilities created
# capabilities reused by a second customer

The second-customer reuse event is especially important.

A capability used once may only be project-specific code.

Reuse by another engagement is stronger evidence of productization.

Human Leverage¶

Track approximately: - repetitive execution hours, - judgment/architecture/review hours.

Desired direction:

REPETITIVE HUMAN EXECUTION ↓
HIGH-VALUE HUMAN JUDGMENT ↑

Delivery Economics¶

Compare first use vs repeated use: - duration, - human effort, - defects/rework, - gross margin, - acceptance speed.

Commercial Proof¶

Track: - offers with credible proof, - proposals using existing proof, - follow-on expansion rate.

20.11 Change Management by Audience¶

Leadership¶

Message:

"We are not abandoning services. We are changing the economics of services by making expertise reusable."

Leadership responsibility: - protect focus, - refuse product sprawl, - reward reuse, - choose commercial wedges, - ensure customer commitments outrank internal Factory experiments.

Collective Members¶

Message:

"Your value is increasingly in judgment, methods, architecture, and exceptional cases — not in being the person who manually repeats a known process."

Do not tell people:

"AI will do your job."

Tell them:

"We want the methods you have learned over twenty years to become organizational capability instead of disappearing when an engagement ends."

Sales / Business Development¶

Message:

"Sell responsibility and proof before resumes and rate cards."

Sales should learn: - defined offers, - proof cards, - expansion paths, - where staffing supports the outcome.

Customers¶

Message:

"You are still getting senior Bluefly accountability. We are changing the machinery underneath delivery so repeatable work is more systematic, measurable, and efficient."

Do not force customers to understand the internal Factory architecture.

20.12 Incentives Must Match the Change¶

If Bluefly only rewards: - billable hours, - individual utilization, - project revenue,

the company will revert to labor economics regardless of its strategy language.

Over time, recognize: - reusable method creation, - successful second reuse, - measurable delivery improvement, - high-quality evidence, - client expansion from successful outcomes, - mentoring the Factory with domain expertise.

This does not require immediate compensation-plan changes.

It does require leadership to visibly value these behaviors.

20.13 Anti-Drift Rules¶

Use these to protect the strategy:

No new offer without a named buyer and problem.
No Factory capability built solely because it is technically interesting.
No customer-specific fork becomes a product by declaration.
No source-only capability may be marketed as runtime-proven.
No staff augmentation engagement should be treated as the strategic destination when a larger outcome can be defined.
No engagement ends without asking what became reusable.
No reusable method is considered truly repeatable until it survives another use.
No internal primitive is the customer value proposition.
Customer delivery always outranks internal productization work.
Human judgment remains explicit wherever risk, architecture, customer commitment, or unresolved evidence requires it.

21. Ninety-Day Transformation Plan¶

Do not attempt a full-company transformation at once.

Days 1–30 — Define and Prove¶

Objectives: - finalize Bluefly strategic narrative; - maintain one living strategy document; - define 3 commercial wedge offers; - prove Factory runtime sufficiently to support claims; - use Forum One/NPS as Migration Factory commercial prototype; - establish offer and proof-card templates; - begin classifying pipeline by offer / intervention / capacity.

Primary offers: 1. Migration Factory 2. Drupal Estate Assurance 3. Agency Delivery Factory

Deliverables: - offer one-pagers; - internal talk track; - proposal gate; - proof registry; - initial metrics baseline.

Days 31–60 — Change Behavior¶

Objectives: - run reuse reviews on active engagements; - begin Reuse Backlog discipline; - convert one existing engagement learning into reusable Factory capability; - use defined-offer language in new proposals; - establish weekly pipeline/offer review; - establish biweekly Factory reuse review.

Success evidence: - at least one proposal sold around a defined responsibility instead of labor; - at least one reusable capability used outside its original project; - clear separation between human judgment and repeatable execution on an active engagement.

Days 61–90 — Prove Commercial Repeatability¶

Objectives: - get second customer or second engagement usage of at least one offer/capability; - convert one project into recurring assurance/managed operations; - measure actual human effort and margin against prior approach; - retire or revise weak offers; - document first credible Bluefly proof cards.

The key 90-day question:

Has Bluefly demonstrated that reusable governed capability can create better customer outcomes and better delivery economics than simply adding more human hours?

If not, adjust the model based on evidence rather than expanding the story.

22. Thomas Alignment Dashboard¶

Thomas should not need to remember the entire strategy mentally.

Maintain a one-page leadership dashboard answering:

THIS QUARTER'S 3 COMMERCIAL WEDGES=
1.
2.
3.

CURRENT PROOF=
What is actually proven?

BIGGEST COMMERCIAL TEST=
What are we trying to learn?

BIGGEST FACTORY TEST=
What runtime capability must be proven?

ACTIVE STRATEGIC CLIENTS=
Which engagements are teaching us reusable methods?

REUSE CREATED THIS MONTH=
What became reusable?

REUSE PROVEN A SECOND TIME=
What has survived another customer/use case?

RECURRING / MANAGED REVENUE=
Current direction.

GENERIC T&M EXPOSURE=
Are we drifting back toward staffing?

NEXT DECISION=
The one strategic choice leadership must make next.

This is the anti-amnesia mechanism for the business strategy.

It should be reviewed weekly and updated based on evidence, not optimism.