The update left the app not working properly for roughly one in three users. The response was a full rebuild of both mobile apps that reused none of the original code, alongside a redesigned architecture and redundant infrastructure sized for the traffic the product had actually reached.
Case study
We shipped fast enough to grow, and fast enough to break.
2013–2014 · CIS · iOS + Android · Public. A product that grew faster than its foundations, and what it cost to put them back.
What it was
easy10 was a language-learning product built on a single promise: ten words a day. Small enough to do on a commute, structured enough to compound.
The first version was built very quickly, and that speed did exactly what it was supposed to do — it got a real product in front of real users while the idea was still worth testing.
What growth looked like
| Users in the first three months | 200,000 |
| Weekly growth | around 20% |
| Daily actives at the time | around 15,000 |
| One acquisition campaign | 80,000 downloads |
| Later public reporting | 500,000+ downloads |
| Seed investment | around $450,000, after a three-month IIDF accelerator |
By every measure a young consumer product is judged on, this was working.
What broke
iOS 7 shipped.
After the update, the app stopped working properly for roughly one in three users — not a cosmetic regression, a third of the install base unable to use the product they had just been acquired into.
This is the part worth being precise about. The OS release did not cause the failure. It revealed it. The first version had been built at maximum speed, and speed had been paid for with assumptions that only held while the platform underneath stayed still. Platforms do not stay still.
The decision
The rebuild reused none of the original code.
That is a heavier call than it sounds. Rewriting from scratch is usually the wrong instinct — it throws away working behaviour along with the debt, and it stops the roadmap for as long as it takes. It was the right call here because the original was not a codebase with problems in it. It was a prototype that had been left in production while 200,000 people arrived.
Around the rewrite: a redesigned architecture, redundant infrastructure sized for the load the product had actually reached rather than the load it launched with, both mobile apps rebuilt, and a delivery team assembled to keep it standing afterwards.
What this proves
| Claim | Evidence |
|---|---|
| Shipping fast worked | 200,000 users in three months, ~20% weekly growth, ~15,000 daily actives |
| The market was real | ~$450,000 seed after a three-month IIDF accelerator |
| Speed was borrowed, not free | one OS release left roughly one in three users unable to use the app |
| The debt was structural, not incidental | the rebuild reused none of the original code |
| The product outlived the crisis | still shipping today; its App Store listing now claims 1.5M users |
What it does not prove
- It does not prove the first version was a mistake. Without it there would have been no 200,000 users and no funding round.
- It does not prove rewrites are the answer. They are the answer when what you have is a prototype in production, and rarely otherwise.
- It does not prove the growth was durable. Three months of steep growth is a signal, not a business.
What we would do differently
Decide up front what the fast version is allowed to be, and set the date it stops being allowed to be that.
The cost here was not writing a quick first version — that was correct. The cost was that nothing forced a reckoning until an external event did. A prototype that succeeds gets promoted to production by default, silently, and then a platform release picks the moment for you.
This is why Proof Engine separates the test asset from the product. An asset built to answer a question is allowed to be disposable. It is only dangerous when nobody says out loud that it was.
Where it is now
easy10 is still in the App Store a decade after the rebuild, and its current listing claims 1.5 million users.
Public sources from the period, for anyone who wants to check the numbers rather than take them from us:
FAQ
Frequently asked questions
Here, yes — because what was in production was a prototype, not a codebase with problems in it. Rewrites are usually the wrong instinct: they discard working behaviour along with the debt and freeze the roadmap. The test is whether you are throwing away a product or a placeholder.
About 200,000 users in the first three months, roughly 20% weekly growth, and around 15,000 daily actives. One acquisition campaign alone produced 80,000 downloads.
Yes. easy10 is still shipping a decade later; its App Store listing now claims 1.5 million users.
Speed is a loan. Taking it is usually right — it is how you find out whether anything is there. The mistake is not setting the date it comes due, because if you do not pick that date, an OS release will pick it for you.
Prefer a conversation first?
If you would rather talk it through before sending a brief, book a short routing call and we will point you to the right next step.