Tripleblue · May 2024 – present
Taking a product off low-code without losing a feature
Rebuilt a FlutterFlow web and mobile product as a custom Next.js and Flutter stack on Supabase, at full feature parity, while the original stayed live.
- Role
- Full-Stack Developer
- Team
- Small product team with a dedicated designer
- Timeline
- May 2024 – present
Outcomes
- Feature parity at cutover
- 100%
- Clients rebuilt (web + mobile) on one backend
- 2
The problem
Tripleblue's first version was built in FlutterFlow, which got the product in front of users quickly. It then hit the ceiling that low-code platforms have: the features that mattered next — reliable background audio recording, offline access, a data model that could evolve — were the ones the platform made hardest. The product could not grow without leaving the tool it was born in.
Constraints
- The existing platform had real users and had to stay live and stable throughout
- Feature parity was non-negotiable — a rebuild that lost capability is a downgrade
- Two clients to rebuild, web and mobile, against one backend
- Designer-led: implementation had to match Figma closely, not approximately
Approach
I kept the FlutterFlow version maintained and shipping while building its replacement alongside it — bugs in the old platform still got fixed, including the native audio and iOS file persistence issues. The web app was rebuilt in Next.js and the mobile app in Flutter, both against a Supabase backend whose schema was designed properly rather than inherited from the low-code tool's assumptions. Reusable component structures came first, so that the second half of the rebuild went faster than the first.
What I rejected, and why
Staying on FlutterFlow and working around the limits
The workarounds were already the majority of the effort. Background audio and offline storage weren't features the platform was missing — they were features it actively fought.
Rebuilding web and mobile against the existing data model
The schema encoded low-code constraints. Carrying it forward would have meant paying for those decisions permanently.
Architecture
The hard part
Background audio recording that survives the OS. On iOS, an app that is recording can be suspended, and files written before suspension can end up in locations that don't persist the way you expect. Getting recording to continue reliably in the background, and getting the resulting file to still be there afterwards, meant working below the framework abstraction — audio session configuration, correct file destinations, and handling the interruptions the OS raises for calls and other audio. This is the class of problem low-code platforms cannot reach, and it's why the rebuild was necessary rather than merely nice.
What I'd do differently
Low-code is a good answer to 'can we prove this works' and a bad answer to 'can this grow'. The mistake isn't starting there — it's not noticing the moment the workarounds cost more than the rebuild would. Keeping the old platform alive during the rebuild was worth every hour it cost, because it removed the deadline pressure that makes rewrites go wrong.
Stack
- Flutter
- React
- Next.js
- TypeScript
- Supabase
- PostgreSQL
- Figma
- FlutterFlow
- iOS
- Android