Rebuilding Cerebro's mobile app in five days
Asif Ahmed
I rebuilt Cerebro’s mobile app natively over five days in March. By the end of the fifth day, the team was using it. The old app was a Capacitor web shell; the new one is Expo and React Native, built for the phone.
Why I rewrote it
The original mobile app was built by an outside agency before I joined 776, using a web-first approach that made sense at the time. By the time I took it over, that app had grown to more than 2,600 commits over about two and a half years. Here is what I inherited: a Capacitor shell that looked like an app but rendered Cerebro as a web page inside a browser view. Over time, shifting priorities left some components marked “not native safe” and some modules split between unfinished v1 and v2 migrations. Fixing it piece by piece would have taken longer than starting clean, so I rebuilt Cerebro for the phone directly.
Once I decided to start clean, the work became a matter of getting from an empty project to something the team could actually use.
Five days
Day 1Mar 10
Expo SDK 54, auth, navigation; fixed the broken iOS build.
Day 2Mar 11
Every tab, detail screen, API layer, and Typesense search.
Day 3Mar 12
Native chat, gestures, deep links, and over-the-air updates.
Day 4Mar 13
Push notifications, timeline reactions, and the first team TestFlight.
Day 5Mar 14
Polished, caught a production bug, hot-fixed it; team onboard.
By the end of those five days, the difference showed up in small, everyday moments. Opening a shared Cerebro link was one of them.
Links that open the app
Cerebro links get shared all day in emails and Slack messages. In the old app, tapping one sent you to a web page instead, breaking your flow and reminding you that the app didn’t feel truly native. I changed that, so those links now open in Cerebro and take you straight to the contact, note, or conversation you wanted, whether the app was already running or not. It’s a small thing, but it makes Cerebro feel like an app instead of a web page in a wrapper.
Building natively changed how the app behaved. Expo also changed how I could ship and fix it.
How it ships now
JavaScript and TypeScript changes go out over the air in seconds, without App Store review. Native changes still need a full rebuild pushed to TestFlight, and those builds expire after 90 days, so I push a fresh one periodically.
The production bug I caught on the last day was a client-side mistake: the app built a chat file attachment as a flat object instead of the nested pieces the server expected. Reading a field that wasn’t there returned an error from a shared endpoint, which broke whole conversations for the rest of the team, not just the sender. Because the fix was JavaScript, it went out over the air with no new build, no review, and no waiting. A mistake that would once have meant a resubmission and days of a broken app was a same-day fix. Updates now land through a small “restart to update” banner, so the change applies when someone is ready.
Now Cerebro can move as quickly on mobile as it does everywhere else. The question is why a rewrite that had waited so long became practical now.
Why it happened now
A native rewrite would normally be a multi-person, multi-month project. With one engineer and a long backlog, the old app worked well enough that replacing it would never have cleared the bar. AI brought the cost down enough for me to rebuild it in a handful of days. That changed the decision itself: a project that had always been “someday” became work I could finish that week.