# Launch27 Replacement Reality

Any serious CleanOS planning must evaluate Launch27 honestly.
The right move may be gradual replacement, partial replacement, or a hybrid architecture for longer than expected.

## What is known

Launch27 still matters because it currently holds or influences:
- booking workflows
- scheduling logic
- service and pricing data
- historical customer and booking context

At the same time:
- the official API is not reliable enough for live scheduling and booking operations
- some live operational work requires direct UI interaction, Playwright automation, Airtable support, or manual verification
- replacing it cleanly is likely harder than it looks from a whiteboard

## What Claude should test

1. Which Launch27 functions are mission-critical today?
2. Which are merely annoying versus strategically dangerous?
3. Which workflows can be wrapped before they are replaced?
4. Which workflows should remain in Launch27 for a transitional period?
5. What is the minimum operational core CleanOS would need to own before replacement becomes worth it?

## Working hypothesis

The most likely good strategy is not:
- rip out Launch27 immediately

The more likely good strategy is:
- identify the highest-value wedge
- own that wedge with a better internal system of record
- integrate or wrap the rest temporarily
- only replace more when operational truth and migration risk are manageable

## Warning

A lot of product concepts look good until they hit real scheduling edge cases, recurring cadence rules, reschedules, exceptions, assignments, and availability conflicts.
Claude should not hand-wave these away.