Bluefly Technology Reduction: Sales Package¶

Customer-facing. Definition: offer.md. Everything below is ready to send or publish as written.

A. One-page offer sheet¶

Stop maintaining what you no longer need.¶

The problem. Over the years your organisation built custom integrations, modules, scripts and workarounds, each one for a good reason at the time. Your platforms have since caught up. Many of those custom pieces now duplicate something your existing systems do out of the box. You still pay to maintain every one of them: in upgrades that take longer than they should, in security reviews, in access that nobody can fully explain, and in the one person who knows how it works.

What we do. We find the custom technology you're still maintaining that your existing systems can now replace. We prove each one can safely go away, and we help you remove it.

Who it's for. Organisations running established platforms with years of accumulated customisation, especially across several sites or applications. It suits IT leaders who own the upgrade bill and the risk register.

When to buy. - A forced upgrade or end-of-life date is coming, and the custom work is what makes it hard. - Upgrades take weeks of testing that nobody can justify any more. - A security review turned up access or credentials nobody can explain. - One person is the only one who understands a critical piece. - You're standardising several sites or applications on one platform.

What you get. 1. Maintenance Review. A fixed-scope review of what you own. Every item gets a verdict: keep, retire, replace, consolidate, or investigate. 2. Deletion Plan. A ranked, decision-ready list: what to remove now, next, later, and what to keep. Each item comes with its replacement, its risk, and its rollback path. 3. Safe Removal (optional). We remove the approved items. Old and new run side by side, your team signs off, and a rollback window stays open until the result is proven. 4. Maintenance Watch (optional). A short quarterly report covering what you can stop maintaining now, and what you're about to build that you shouldn't.

How it works. Review → you decide → we remove → we prove it → we watch.

Business value. Fewer things to upgrade, secure and staff. Upgrades get faster because there's less to test. Access points get closed instead of documented. Knowledge that lived in one person's head stops being a risk.

How success is measured. By what you no longer have to own: systems retired, maintenance hours returned, access points closed, upgrade testing removed, and single-person dependencies removed. Cost savings are reported only where your own figures support them.

What it is not. It isn't a rewrite, a new platform to buy, or staff augmentation. If something should stay, we tell you.

Next step. Find out what you can stop maintaining. Book a 30-minute qualification call. Leave with a clear yes or no on whether a Maintenance Review is worth it for you.

B. Landing page copy¶

HERO_HEADLINE: Stop maintaining what you no longer need.

HERO_SUBHEAD: We find the 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.

PRIMARY_CTA: Find out what you can stop maintaining.

PROBLEM_SECTION Your platforms caught up. Your maintenance bill didn't. Every custom integration, module and workaround made sense when it was built. Many now duplicate what your platform does on its own, but you still upgrade them, test them, secure them, and depend on whoever remembers how they work. That cost is real, and it doesn't show up as a line item.

HOW_IT_WORKS 1. Review. A fixed-scope Maintenance Review of what you own. Every item gets a clear verdict. 2. Decide. You get a Deletion Plan ranked now / next / later / keep. Each item shows what replaces it and how risky removal is. 3. Remove. We run old and new side by side, and you approve the switch. A rollback window stays open until the result is proven. 4. Watch. Each quarter we tell you what you can stop maintaining now, and what you're about to build that you shouldn't.

WHAT_YOU_GET - A complete inventory of the custom technology you maintain, with an owner and a reason for each piece. - A Deletion Plan you can act on, with or without us. - Removals proven to keep the same business outcome. - Credentials and access from retired systems closed, not just documented. - A short quarterly report instead of a dashboard nobody reads.

WHY_BLUEFLY We measure ourselves by what you no longer have to own, not by code written or hours billed. Our default answer to "should we build this?" is no. We start from what your existing platforms already do, and we tell you when something should stay.

BUYING_TRIGGERS - A forced upgrade or end-of-life deadline. - Upgrades that take weeks of regression testing. - Security findings involving unexplained access or credentials. - Critical knowledge held by one person. - Several sites or applications being brought onto one platform. - Custom code growing faster than anyone can review it.

METRICS Systems retired · Maintenance hours returned · Access points closed · Upgrade testing removed · Single-person dependencies removed. Cost savings are reported only where your numbers support them.

FAQ - Is this a rewrite? No. We remove. Where something should stay, the plan says keep. - Do we have to buy new software? No. Your existing platforms are the replacement. - Can our team do the removals themselves? Yes. The Deletion Plan is built to be acted on by anyone. - What if removing something breaks? Old and new run side by side first, you approve the switch, and a rollback window stays open until production is verified. - How long does a Review take? It's fixed-scope and sized to a bounded estate: a set of sites, applications or repositories, or one business unit. - How do you know what it costs us to maintain? We work from your evidence: tickets, upgrade records, hours. Where the evidence isn't there, we say so and leave it out.

FINAL_CTA: Find out what you can stop maintaining. → Book a qualification call

C. Sales deck outline (8 slides)¶

Why you're maintaining too much. Your platform caught up with your custom work, but your maintenance bill still covers both.
Why this happens. Every piece was justified when it was built. Nobody is accountable for removing things, so ownership only ever grows.
What Bluefly does. Find what your existing systems can now replace, prove it can go, and remove it.
The Maintenance Review. Fixed scope, a verdict per item, and the Deletion Plan (now / next / later / keep).
Safe Removal. Side by side, customer approval, a rollback window, and access closed. Same outcome, less machinery.
Maintenance Watch. Two lists a quarter: what you can stop maintaining now, and what you're about to build that you shouldn't.
How success is measured. What you no longer have to own. Five measures, with savings only on your evidence.
Start here. A 30-minute qualification call, then a fixed-scope Review.

D. Talk track¶

10 seconds. We help you stop maintaining custom technology your existing platforms can now replace.

30 seconds. Most organisations are still upgrading, securing and staffing custom work their platform made redundant years ago. We review what you own, give you a ranked plan of what can safely go, and, if you want, remove it with a side-by-side check and a rollback window. We measure success by what you no longer have to own.

2 minutes. Every custom integration and module was the right call when it was built. But platforms move. A lot of what you built is now a feature of the system you already pay for, and you're still carrying the old version: it slows every upgrade, adds to every security review, and usually depends on one person. We start with a fixed-scope Maintenance Review. Every item gets a verdict: keep, retire, replace, consolidate, or investigate. That becomes a Deletion Plan ranked now, next, later, keep, with the replacement, the risk and the rollback path for each item. You can act on it yourselves. If you want us to do the removals, we run old and new side by side, you approve the switch, and we keep a rollback window open until production is proven, then close the old access. After that, a short quarterly Watch tells you what's newly removable and what you're about to build that you shouldn't. We don't count hours or code. We count what you stopped owning.

Objections - "Why can't my team do this?" They can do the removals, and the plan is built for that. What teams rarely have is the time and the mandate to question things that already work. The Review gives you an outside, evidence-based verdict on each item, so the decision isn't one engineer's opinion against another's. - "Are you just trying to sell us another rewrite?" No. The output is a list of things to remove, and every item names the existing system that replaces it. If nothing qualifies, the plan says keep, and you've lost nothing but the Review. - "What if the custom solution is still better?" Then the verdict is keep, and the plan records why. Better is judged against the business outcome you need, not against whether code exists. - "What happens if removing something breaks?" Nothing switches until old and new have run side by side and you've approved the result. The old implementation stays available through a rollback window, 30 days by default or longer where your operations or regulators require it. It's only removed after production is verified. - "How do you know what we actually spend maintaining it?" From your evidence: tickets, upgrade and test records, hours, incidents. Every figure we report shows its source and whether you've confirmed it. Where there's no evidence, we leave it out rather than guess.

E. Qualification worksheet (one conversation)¶

Ask, note the evidence, and tick. No scoring formula.

Signal	Ask	Evidence that counts
`FORCED_UPGRADE_WITH_DATE`	Is there an upgrade you can't avoid, with a date?	Named version and date
`END_OF_LIFE_DEADLINE`	Is anything reaching end of life or end of support?	Vendor date
`CUSTOMIZATION_COUNT`	Roughly how many custom modules or integrations?	A number, even a range
`UPGRADE_DIFFICULTY`	How long did the last major upgrade take?	Weeks or months, and why
`MAINTENANCE_COST_PRESSURE`	Is someone asking you to cut run cost?	Budget target or mandate
`SECURITY_FINDINGS`	Any open findings on custom code or access?	Audit or pen-test item
`UNEXPLAINED_CREDENTIALS`	Is there access nobody can fully account for?	Yes, with an example
`KEY_PERSON_DEPENDENCIES`	Is there a piece only one person understands?	Named system
`DUPLICATE_CAPABILITIES`	Do you do the same thing two ways?	Example
`AI_GENERATED_CUSTOM_CODE_GROWTH`	Is custom code growing faster than review?	Example or trend
`NUMBER_OF_SITES_OR_APPLICATIONS`	How many sites or applications are in scope?	Count
`PLATFORM_STANDARDIZATION_OPPORTUNITY`	Are several of them on, or moving to, one platform?	Yes / planned

IDEAL_FIT: a dated forced upgrade or end of life, plus at least two of customisation count, upgrade difficulty, security findings, key-person dependency, duplicate capabilities, plus a scope we can bound (sites, applications, repositories, or one business unit). → Offer a Maintenance Review.

POSSIBLE_FIT: clear signals but no date or no budget owner. → Offer the qualification call outcome in writing and revisit at the next upgrade cycle.

BAD_FIT: little customisation, no upgrade pressure, no named owner, or the ask is actually "build us something new." → Decline politely and say why.