Most acquisitions that go bad don't blow up. They slow down.
The product keeps working. The numbers stay green. And a year later everyone realizes the thing they paid for stopped being special somewhere along the way, and nobody can point to the day it happened. That's the failure I'd be hired to prevent, and this is how I'd run the first 90 days to catch it while there's still time.
The deal
In mid-August 2026, Stripe reportedly agreed to buy OpenRouter for more than $7 billion.
If you haven't used it: OpenRouter is one door to the entire AI model market. One key, one bill, instant access to 400-plus models from dozens of providers. Roughly eight million developers use it. When a hot new model drops, OpenRouter usually has it within days.
Stripe already runs the billing and payments underneath a lot of the AI economy. OpenRouter is the layer that sits one step earlier and decides which model handles each request. So the $7 billion buys two things: that routing decision, and a live feed of which models are actually winning real production traffic.
What's actually at risk
Here's the part that matters. OpenRouter isn't valuable because of its code. It's valuable because of two things that don't show up on a balance sheet:
- Speed. New models appear almost the week they ship.
- Trust. Developers believe the routing is neutral, not steering them toward whoever pays.
Neither of those is protected by the purchase. Both can quietly erode, and here's how it happens with acquired dev tools, every time:
- The team turns inward to handle the integration
- Shipping slows by a release here, a week there
- New models get added a little later than before
- The community waits a little longer for answers
Every one of those is small. None trips an alarm. And revenue looks fine the whole way, because revenue only drops after developers have already started leaving.
Why it's invisible
At eight million developers, small slowdowns compound fast. Switching routers is a config change, not a migration. So the math that should scare Stripe isn't one missed release:
And nobody files a ticket about a gap. A developer doesn't email you to say your cadence dropped. They just notice a rival shipped the model they wanted first, and they move one project over. Then another.
This is the trap, in one picture:
So the real question isn't can Stripe integrate OpenRouter. It's: how do you see it slowing down while you can still do something about it?
The instrument
I've watched a version of this before. On a large program at Accenture, the shared status log was solid for about six weeks, then quietly went thin, and a team that had stopped reporting looked exactly like a team with nothing wrong. So I built something small that surfaced whatever had gone untouched, instead of waiting for someone to notice. Same instinct here, one twist: in an acquisition nothing goes silent. Everything keeps moving. You're not hunting for silence. You're hunting for deceleration.
So I built a mock to make it concrete: a velocity monitor. It watches six signals, and it never asks "is this number good." It asks "is this number bending away from where it was, and from where a rival is heading." Because a product can post healthy numbers and be dying at the same time, and the only way to see it is to compare the slope against a baseline you captured before anything changed.
The 90 days
My job in one line: keep OpenRouter shipping at least as fast as it did the week before the deal, and be able to prove it.
Days 1-30
Baseline the speed before touching anything
You can only prove a slowdown against a "before"
Days 31-60
Lock in the people and the promises, publicly
The team and the neutrality are the asset
Days 61-90
Add Stripe's tools as opt-in, never forced
Forced migration is how the slope starts
Days 1-30 — measure before you touch. Capture OpenRouter's speed today, before anything merges: releases per week, days to add a big new model, changelog frequency, community response time, doc freshness. These become the "before" lines in the monitor, and this is the only window to catch them clean. Miss it and you lose the ability to ever prove the product slowed, because you'll have nothing to compare against.
Days 31-60 — protect what walks out the door. Two assets leave quietly if you let them:
- The people. The founders and the ~15 engineers who run routing and provider deals. Roughly a third of acquired employees leave within a year, and the senior ones go first. Retention has to be real roles and authority, not just an earnout.
- The promise. OpenRouter is trusted because it doesn't favor any provider. A payments giant owning it invites exactly that suspicion. So publish dated commitments in plain sight: keys keep working, pricing frozen a year, routing stays neutral, prompts never used for training. Public promises are expensive to quietly break. That's the point of making them public.
Days 61-90 — add value without taking any. Stripe genuinely has things these developers want: better metering, global invoicing, tax. Every one ships as opt-in. The way acquired products die is the parent's roadmap quietly replacing the acquired one, until the thing people loved becomes a funnel to something they didn't ask for. Scale Stripe's agenda before OpenRouter has proven it kept its speed, and you've turned a $7 billion asset into a maintenance project.
Why this order: the baseline makes phase two provable instead of hopeful. Protecting the people and the promise keeps a community alive long enough for phase three to matter. Do it backwards and you learn the velocity dropped only after the developers who noticed are already gone.
What "done" looks like at day 90
- Every speed signal is at or above where it was before the deal
- Zero founder or senior-infra departures, or a real succession plan if one happened
- The public pricing, neutrality, and data promises are all still true
Underneath all of it is one idea about what to measure. Most integrations get graded on lagging numbers: revenue kept, customers churned, headcount retained. Those only move after it's too late. Velocity divergence moves early, because a product shipping 30% slower than it used to, in a market where the rival is speeding up, is already losing, even while this quarter looks great.
I'd rather watch the number that warns me than the one that files the report.
An acquired product rarely dies because someone kills it. It dies because it slows down while everyone's still watching the numbers that stay green the longest.
If you've run an integration like this and think I've got it backwards, I'd genuinely like to hear why.
The velocity monitor from this post is live here. Mock data, six signals, one question: is it bending away from where it was?
Sources: Stripe's reported acquisition of OpenRouter (Bloomberg, Axios); terms are press-reported and were not officially confirmed as of publication. Scale figures from OpenRouter's published materials and Series B coverage. Attrition rates from MIT Sloan's Predictable Exodus and Revelio Labs.