Strategy
We Rebuilt Streaks Three Times at Flalingo. Then I Stopped Rebuilding.
We Rebuilt Streaks Three Times at Flalingo. Then I Stopped Rebuilding.
It was the third time I was specifying buddy progression in a Notion doc.
The design team had finally landed on the widget. Beautiful. Evolution stages, coin economy, badge taxonomy, streak grace days. Everyone wanted it shipped by quarter end.
And I stopped.
Because I had specced almost exactly this same thing in 2023. And again in 2024 after we ripped half of it out. And here I was, mid-2025, opening Linear and creating a third epic with the same shape: event model, state machine, idempotency layer, widget surfaces.
Same dance, third time.
That morning I closed the doc and didn't open it again. I walked over to my second screen and started writing something else. Not another epic. A microservice. A different kind of project, where the whole gamification layer would live outside Flalingo, behind a config and an API, never to be rebuilt inside our product code again.
I didn't know it yet but I was joining a pattern. Every infrastructure category in the last fifteen years got unbundled the same way. The fourth time someone refused to build it in house, and built a tool instead.
This is that story. And the one before it.
The Receipt
Three rebuilds at Flalingo. Let me show you what each cost.
First version, 2023. A simple table tracking xp_per_student, badges_earned, last_streak_day. Cron jobs at midnight to roll streaks forward. UI wired into the student dashboard directly. Two engineers, six weeks. It shipped. It worked. For a while.
Then we tried to add a buddy, the pet that grows as you learn. Suddenly the engagement model needed a state machine, the progression had stages, the widget had to live somewhere other than the dashboard. Six weeks of refactor.
Then we added a marketplace. Coins, items, equip slots. The badge table didn't accommodate that, we wrote a new one. Two more engineers joined for a sprint. Then the streak logic broke for users in timezones we hadn't tested. A handful of students lost 90-day streaks during a migration. Support tickets. Internal Slack. I remember the question landing in my DMs: "Hayreddin, why is this still happening?"
Second version, 2024. Full rewrite. Event sourced this time. Idempotent operations. Proper webhook out. Three engineers, ten weeks. Better.
Then we added paths, the guided journey through curriculum. The path metadata didn't fit cleanly into the event sourced model, we ended up with a second store. Six weeks. Then leaderboards came back as a feature request, and we hit a race condition under load (200+ rank shuffles per second during peak class hours). Four weeks of debugging.
Third version, mid-2025. I personally rewrote the state engine over four weekends. The team was tired of the topic. Then designs landed for buddy evolution and the marketplace UI, and the existing schema didn't accommodate evolution stages.
I opened the spec doc.
And that's the day I stopped.
The honest receipt is somewhere between 30 and 40 engineer-weeks, across three years, for a feature category that's never been the reason a student stayed or left.
And the harder truth: gamification is genuinely hard to design well. The mechanics look simple from the outside. A streak, a badge, a coin. From the inside it's three different categories of work happening simultaneously, every event has to be collected consistently across every product surface, every progression has to be visible without drowning the UI, every consistency rule has to hold across timezone, migration, replay. Three rebuilds didn't fix it because none of them was ever a "feature" project. Each was a small platform project we kept pretending was a feature.
It Wasn't Just Us
For a while I told myself this was a Flalingo problem. We move fast. We change designs. We expect more than we should from internal tools.
Then I started looking around.
When I was at OSF Digital between 2018 and 2020, I helped build Salesforce Commerce Cloud projects for some of the largest retail brands in Europe. One of them was Ubisoft.
Yes, that Ubisoft. The company whose entire industry is built on gamification mechanics. People who invented the operational concept of XP, levels, achievements, and quests at consumer scale.
We helped them ship a loyalty and rewards layer for the Ubisoft Store. Points for purchases, badges for milestones, a marketplace for exclusive items. The kind of mechanics they ship in their own games inside a sprint.
The store implementation took two quarters.
Six months. For a simple version. At Ubisoft.
And it shipped well. The team was excellent. The project was successful by any reasonable measure. The point isn't that they struggled. The point is that even a gaming company, the people who literally invented these mechanics, treated a basic loyalty layer as a two quarter project, because the moment you move gamification from the game into a separate product surface, you're rebuilding everything: event ingestion, state, rules, idempotency, widgets, analytics, anti-abuse.
It's not a small project. Not for them. Not for anyone.
After Ubisoft, I started counting. At Internetstores, the largest bike and outdoor retailer in Europe, the engagement layer was a never finished side project. At Algolia, I watched multiple B2C customers wire badges and streaks through our event APIs in ways that were beautiful for two months and unmaintainable for two years. At Flalingo, I led three of these rebuilds myself.
Three different industries. Three different scales. Always the same shape.
A team budgets four weeks. It ships in twelve. It works for a quarter. It needs a rewrite in eighteen months.
This is not a developer skill problem. It's an architectural pattern that doesn't belong inside the application. Every team that ships engagement features ends up running, separately and badly, the same small platform: an event store, a state machine, a rules engine, a widget delivery system, and an analytics layer for things they didn't track but now have to.
Sound familiar? It should. That's the same shape as auth before Auth0. As payments before Stripe.
This Is the Auth Story Again
In 2012 every B2C product had its own auth code. A users table. Salting and hashing in app logic. A password reset flow held together by hope. Then OAuth happened, then social login, then 2FA, then SSO. Each new requirement added two weeks to a sprint for every team in the world, in parallel.
By 2015 Auth0 was raising at unicorn pace. By 2021 Okta acquired it for $6.5 billion. The pattern was so universal that the second order effects rippled across every SaaS stack. Today, in 2026, almost nobody serious writes their own auth. We don't think about it. We delegate.
The same story ran in payments. Pre-Stripe you needed a merchant account, a payment gateway, fraud logic, PCI compliance, and a frontend integration. Patrick Collison's pitch in 2010 was deceptively simple: seven lines of code. By 2021 Stripe was valued at $95 billion. Every developer I know reaches for it before thinking. The category became invisible.
Same with search. I joined Algolia in 2023 in part because I was fascinated by the unbundling logic. Before Algolia, every product team wrote its own fuzzy match, typo tolerance, faceted filtering, multi index ranking. Then Algolia and Elasticsearch existed and search became a paragraph in the API spec instead of a quarter on the roadmap.
The pattern is stable. It works like this:
Stage one. Every product builds it internally. Considered a core differentiator.
Stage two. A few teams realize it's the same shape everywhere. Considered a "we should extract this" idea that nobody has time for.
Stage three. Someone builds it as a platform. Charges per event, per seat, per request. Other teams try it for the first low risk surface.
Stage four. A generation of products that grew up post extraction never even consider building it. The category becomes invisible.
Auth went through this between 2012 and 2018. Payments between 2010 and 2015. Search between 2013 and 2019. Communications (Twilio, SendGrid) between 2010 and 2016.
In every case, the people inside the abstraction layer thought they were special. Our auth is different. Our payment flow has unique requirements. Our search has domain specific ranking. In every case, eighty percent of the work turned out to be the generic part, and the unique part turned out to be a thin layer of configuration on top.
Engagement is sitting in stage two right now. Maybe stage three. Every consumer product, every PLG SaaS, every EdTech, every fitness app, every onboarding flow ships streaks, badges, XP, paths, leaderboards. Every one of them builds it badly the first time, rebuilds it once or twice, and ends up with a quarter of their engineering team owning a small platform they never wanted to operate.
Jeff Lawson, Twilio's founder, has a useful framing for this: the categories worth extracting are the ones where every developer ends up writing the same module. Engagement is the next obvious one.
Why Now
I'd have lost this bet in 2021. Retention pressure wasn't existential. CAC was tolerable. The marginal user could be acquired.
That window closed.
In 2026 every consumer product is fighting for time on the same handful of attention surfaces. Activation rates have flatlined. The 30-day retention curves at most B2C apps look identical: 80% drop by week one, the long tail by month three. The teams that survive are the ones who make every meaningful action feel like progress.
Duolingo isn't a language app. It's a streak operating system that happens to teach Spanish. Strava isn't a tracker, it's a public progression layer. Notion's onboarding has paths, quests, badge ceremonies for finishing the first doc. Replit shipped XP and leveling for using their AI before it shipped half its roadmap.
The smartest product teams now treat engagement as a top three product investment. Not a polish layer. Not a Q4 sprint.
And here's the kicker. AI made everything else cheaper to build. Earlier this year I wrote about replacing two annual SaaS contracts in 15 days with agentic engineering. The "build it yourself" calculus shifted dramatically for most categories.
But engagement is the one place where "build it yourself" is exactly the wrong move, because the build cost was never the writing of the first version. It was the second rebuild. The third. The fourth.
The Schumpeter wind that's killing rental SaaS for CRM and helpdesks is the same wind that creates pressure for infrastructure layers where rebuilding internally has compounding cost. Auth, payments, search, and now engagement.
Same destruction. Different layer.
What I'm Building
Six months ago I sat down and stopped writing my fourth engagement spec at Flalingo. I started writing something else.
It's called Hatched.live. It's an API that takes customer events and returns progression: buddy state, skill graph, coins, badges, streaks, paths, marketplace, leaderboard, evolution stages. You send lesson_completed. It returns the state delta. One script tag renders the widget. Your data stays yours. Your UI stays yours. You stop owning the platform.
I'm building it because I was the person rebuilding this stack at Flalingo. I'm building it because I watched Ubisoft spend two quarters on it. I'm building it because, after three rounds inside one product, I am pretty sure I know which parts are generic (almost all of them) and which parts are not (a thin configuration layer on top).
It's early. We're in design partner phase, working with a handful of EdTech, fitness, and PLG SaaS teams who need this layer immediately. If your team has shipped an engagement feature in the last twelve months and the maintenance burden is starting to feel familiar, find me at hatched.live.
I'll keep writing about what I learn here. Same place. Same voice.
The Honest Part
This isn't for everyone.
If your product has two hundred users and a single streak counter, build it yourself. The day it stops being a single counter, you'll know.
If you ship a casino or a regulated gambling product, what you need isn't engagement infrastructure, it's Smartico or Optimove with compliance teams behind them. Different category. I'm not playing there.
If you're an enterprise loyalty stack with a dedicated rewards team and a custom data warehouse, you've already crossed the threshold. You don't need a layer, you need a vendor with a six month deployment.
The Hatched bet is on the middle. The team that's shipping a real product, has real users, treats retention as a top three metric, and is two weeks into discovering that the rewards table they just added is going to grow into a small platform they don't want to maintain.
It's also a timing bet. Engagement might still be 18 months early as a category. Auth in 2011 felt early too. I'd rather build the layer too soon than discover I was right and someone else did it.
Maybe wrong. Building anyway.
The Wind, Again
I closed the SaaS Is Dead piece with a line from Schumpeter. The wind of creative destruction doesn't ask permission.
It doesn't.
Auth was extracted. Payments were extracted. Search was extracted. Communications were extracted.
Engagement is next. Someone is going to build the layer that the next generation of products never has to think about. I rebuilt streaks three times to learn this. The fourth time, I stopped rebuilding.
You'll thank the layer when you forget it exists.
Hayreddin Tüzel
Co-Founder & CTO @ Flalingo
Founder @ Hatched.live
Building gamification infrastructure for products that can't afford to build it twice