Build it, or buy it
Six chapters, ten minutes. The method is settled; what is left is who runs it. This act makes the case for buying rather than building — which holds for any competent vendor — and then makes ours: what working with us looks like, what stays yours regardless, the questions your team will ask, what the rail is worth once the campaign closes, and the ladder from a sixty-second audit to a migrated book.
Get the one-page summary, written for your role.
Build vs buy
Capability is not the question. The question is what you would be choosing not to build — and it is the same question whoever you buy from.
Build it
Time to first wave
Two to three quarters, most of it spent learning what this document already contains.
Who owns it
No natural owner — not product, not growth, not platform.
What you learn
Your own mistakes, on your own book, at full price.
What happens after
The project closes, but eligibility keeps arriving. Maintained by whoever is left, or not at all.
Cost shape
Salaried, fixed, and payable whether the base migrates or not.
Buy it
Time to first wave
Weeks. The method arrives already argued.
Who owns it
A team whose only job is this, accountable to your gates.
What you learn
What has already been paid for elsewhere.
What happens after
Each quarter’s newly eligible cohorts run on the same gates. Stop whenever you like — the rail was yours throughout.
Cost shape
Indexed to what actually migrates.
It is a campaign, not a project
The first pass moves the book that is ready today. It does not move the subscriber who was dormant in March and re-engaged in June, the cohort that had two months of tenure and now has nine, or the at-risk profile that has since settled. Eligibility keeps arriving, and the subscribers who declined are worth a considered second approach on a later renewal — not a resend. A project ships once and closes; this needs an owner in the second year and the third.
Your subscribers are not a staging dataset
Billing is revenue-critical infrastructure. A v1 mistake here is not a bug ticket — it is churn, disputes, and trust that does not A/B back. Everything in Acts II and III exists because those mistakes have already been made and paid for somewhere else.
A migration has no natural owner
It is not product, not growth, not platform — which is why in-house versions ship late and get maintained by whoever drew the short straw. For anyone who does this as their whole job, the playbook is the roadmap.
The calendar is the biggest line item
At the reference book, the stores take roughly $21K a week — funded or not, decided or not. An in-house build is quarters before wave one; a pilot is weeks. Compare the calendar before comparing the cost, because the delay is paid in store fees either way.
Working with us
You approve the decisions. We run the workflow.
Your team
Approvals
Cohorts, messaging, offer framing, and the stakeholder sign-offs already gathered before signature.
Access
Read access to your subscriber and billing data, a review of the entitlement path, and brand approval on the surfaces. It is a review, not a build — no branch, no release, no roadmap slot.
Policy
Support and cancellation rules — your policy, applied by our scripts. Existing lifecycle, paywall, recovery and winback campaigns are paused or made state-aware before the first send, so a migrating subscriber never receives a store-billing message.
Recurr
Operations
We draft the messaging, cadence and surfaces in your brand for your approval, then run the sends, the checkout path, the billing transition, the monitoring and the reporting.
The model
Cohort selection, timing, offer design, and the gate thresholds — proposed with reasoning, never applied unilaterally.
Accountability
One named owner for a program that touches billing, product, support and finance at once.
Two surfaces carry it. Before signature, a Migration Hub — an async room where finance, technical, product, support and legal each see the same program from their own angle, and approve their own part without every stakeholder joining every call. Finance gets the model assumptions, the eligible base, the fee basis and the cash-flow timing in one place rather than as spreadsheet archaeology.
After signature the room becomes a Migration Dashboard: onboarding, cohort status, gate readings, billing health and support signal, live. The sales conversation ends; the operating record starts. Both are role-aware, so bringing in a new stakeholder does not mean handing them the controls.
What stays yours
A migration off app-store lock-in should not create a second one.
The rail is yours from the first wave, not handed over when the program ends. That is a structural choice, and it is what bounds your exposure to us.
Yours, from the first wave
The rail
Your Stripe account. You own it before the first wave and after the last one.
The subscribers
Your customer records, subscriptions and payment history, in your account.
The surfaces
Your domain, your sender identity, your branded checkout and billing pages.
The entitlements
Your access model and entitlement provider, untouched.
The record
Data exports and the full reporting history of every wave.
Operated by us
Our operations
The decisioning, the migration and ascension workflows, and the lifecycle motions.
Our reporting
Cohort reporting and day-to-day program operations.
Only the right-hand column depends on us. Stop working with us and billing continues — the migrated book keeps renewing on rails that were always yours.
The questions
Seven questions every serious evaluation asks, answered straight. Then six to settle before any migration.
Won’t this churn subscribers?
Doesn’t our SDK vendor already do this?
Is this against store policy?
Do we take on the tax problem?
What happens to support load?
What if the pilot says no?
Who holds our subscriber data?
And six to settle before you launch a migration
Who models what each market nets?
Who keeps localisation scope from growing?
Who decides the payment methods?
Who re-bases the analytics?
Who owns wave-week support?
Whose job is the monthly reconciliation?
What the rail is worth afterwards
The migration finishes in ten weeks. The rail it leaves behind is permanent.
Everything up to here describes a finite campaign: waves fire, cohorts clear, the work closes. That is true of the campaign and false of what it leaves behind. Three things outlast it.
Lifecycle motions become yours. Dunning, winbacks, plan changes and price moves stop being fixed store behaviour and become decisions you set and measure. A price change no longer waits on a store review; a failed payment runs a recovery sequence you set rather than a retry schedule you cannot see.
Acquisition stops paying a toll on its first renewal. Every new subscriber you route to your own checkout arrives on the reclaimed margin from day one, which changes what you can afford to pay to acquire them.
Migration itself never really finishes. The base you could not touch in wave one does not stay untouchable: dormant subscribers re-engage, new store cohorts build tenure, at-risk profiles settle. Each quarter a fresh slice matures into eligibility, and the same cohorting and gates that ran the first campaign run the next one at a fraction of the effort. The book migrates continuously rather than once.
None of that is a reason to migrate. It is the reason the decision is bigger than a project — you are choosing where the billing relationship lives, and that choice keeps paying after the campaign closes.
The ladder
Audit, pilot, migrate. Every step earns the next.
Two of the three are priced, and not in the same shape. One ends; the other is what you are left holding.
Nostos
One-time program
The migration itself — cohorting, waves, gates, the billing transition, the surfaces and the support choreography. Kairos runs inside it at no separate charge. It ends when the book is home.
Oikos
Standing platform
The rail afterwards: your branded surfaces, the lifecycle motions, and the decisioning that keeps reading each subscriber.
Audit
60 secfreeYour store fees and held float, on your ARR and fee mix.
Migration Hub
your pace—Async stakeholder review and approvals, per chapter 13. Kickoff windows are held here.
Pilot
2 weeksfrom $5,000Live migration rate, churn delta against the holdout, billing health.
Migrate
10 weeks5% of migrated paymentsCohort by cohort, each wave released by your approval — four weeks on the optional ramp.
Compound
ongoing2% after year oneThe rail is yours; each quarter’s newly eligible cohorts migrate on the same gates.
When you could start
A reserved kickoff window, not a queue. Availability shows in your Migration Hub before you sign; a window can be held while stakeholders review, and pilot payment converts it to a booked date. Held windows expire rather than sit — capacity is small and deliberately so.
How long it runs
Two weeks from kickoff to the pilot’s go/no-go, then ten weeks for the migration itself — or four on an optional ramp, where healthy cohorts earn a faster cadence. That holds at any book size because the waves are proportional, not fixed: the first is 10% of the addressable base, and each one after is sized by what the gates read. A gate breach pauses a wave rather than the program, so the schedule is a plan the gates can overrule. Subscribers who did not move are re-approached in quarterly waves after that.
Audit
Free. Sixty seconds, no call, no data beyond ARR and fee mix.
Migration Hub
Free. Everything in writing, for review in your own time.
Pilot
From $5,000, sized to the book. Credited in full against migration fees.
Migration Nostos
5% of each payment a migrated subscriber makes in their first twelve months of web billing, then it retires. Billed monthly as you collect it.
The rail afterwards Oikos
Included for a migrated subscriber’s first year on web. After that, 2% of successful payments on the connected web book.
You have read the method. The last thing missing is your own numbers — sixty seconds, and the audit opens with them loaded.