Rewrite vs. Restart: The Plane Decision
Never rewrite a live product with a big customer base; do shut down a small-traction acquisition and rebuild it
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 3
- Confidence
- 88%
A decision rule for whether to rebuild a product. If you have a successful product with hundreds of thousands of customers who hold expectations of it, don't rewrite — that's rebuilding the plane mid-flight and it almost always fails. If instead you've bought a company with modest traction, you can shut the product down and rebuild on your platform — that's merely delaying takeoff: land the trial plane, switch to a better one, take off again.
Origin
Tanguy Crusson's contrast between the failed HipChat/Stride rewrite and the successful pattern of acquiring a small-traction company to rebuild on-platform.
Core principles
- 01The default advice on rewrites is: never — and for good reason
- 02The deciding variable is whether existing customers hold expectations you must not break
- 03Big customer base + expectations = rewriting the plane mid-flight (don't)
- 04Small traction you can shut down = delaying takeoff (fine)
How to run it
- 1
Assess the customer base and its expectations
Determine whether the product already serves a large base with fixed expectations, or has only modest traction you could switch off without major fallout.
Watch out HipChat had hundreds of thousands of daily users when Atlassian rewrote it into Stride — the rewrite finished after Slack and Teams had pulled miles ahead.
- 2
If the base is large — do not rewrite
With a successful product and expectant customers, don't attempt a rewrite. Keep improving it and focus on user problems rather than trying to rebuild the plane in flight.
Pro tip Avoid stacking a rewrite AND a platformization AND a market fight at the same time — all may be necessary, but doing them simultaneously is too much to bite off.
Watch out Trying to win the market, do the rewrite, and platformize simultaneously is a local optimum that can sink the whole bet.
- 3
If traction is small — shut down and rebuild on your platform
With a small-traction acquisition you can shut the product down and rebuild on your own platform to reach your customer base. You're not rebuilding mid-flight; you're delaying takeoff.
In the wild
Atlassian rewrote the already-successful HipChat ('go big' then 'next gen'), producing Stride — a great product that landed after Slack was miles ahead and Microsoft launched Teams. Atlassian ultimately sold HipChat and Stride to Slack and exited the market. Crusson contrasts this with acquiring a small-traction company where you can safely shut the product down and rebuild.
→ The HipChat rewrite failed and the market was exited; the buy-small-and-rebuild pattern is the one he'd repeat.
Common mistakes
Doing rewrite + platformization + market fight at once
Atlassian believed it could win the market, do the rewrite, and platformize components all simultaneously. Each was arguably necessary, but together they were too much — a bad local optimum, even though ~70% of the HipChat code lives on in the Atlassian platform editor today.
Is it for you?
Best for
A product leader deciding whether to rebuild a live product or a newly-acquired one
Not ideal for
Situations with no existing users at all, where the rewrite-vs-restart distinction doesn't apply
From the transcript
“you ask me now I tell you never that's that's what most of the advice is never do a reate”
“it's not the same as trying to rebuild the plane midf flight it's delaying takeoff”
“in one case what you try to do is uh so when you rebuild you've got a successful business you've got hundreds of thousands of…”
“but all of them at the same time was um probably a bit too much to bite”
From the episode
Hard-won lessons building 0 to 1 inside Atlassian
Tanguy Crusson (Head of Jira Product Discovery)