FLOW
One product, four surfaces, one set of rules.
- Role
- Sole developer
- Timeline
- 2026
- Type
- Trading education on web, iOS and Android
- Stack
- NestJS, Next.js, Expo, Prisma, PostgreSQL
The problem
A learner who buys a course on the web expects it on their phone a second later. The moment access rules are written twice, the two surfaces start disagreeing about what someone paid for.
What we built
A monorepo where web, mobile and admin are separate apps over one API, one schema and one entitlement engine. Courses, subscriptions, one-time purchases and market signals all check access through the same server-side rules. The interface works in English and Arabic, right to left included.
My role
I'm the only developer on FLOW. I designed and built all of it: the NestJS API, the PostgreSQL schema, the Next.js web app and admin console, and the Expo app for iOS and Android.
How it fits together
- Next.js for the web app and the admin console
- Expo client for iOS and Android
- NestJS API with one central entitlement engine
- Prisma and PostgreSQL data layer
The hard part
Keeping one definition of what a user is entitled to while three clients, two purchase models and a payment provider all ask the question differently, and enforcing the answer on the server, never in the interface.
Where it stands
The API, the database and the admin console are live. The web app and the mobile apps are built and tested end to end, and the public launch is planned for October 2026. Every feature is covered by integration tests against a real PostgreSQL database, not a mocked one.
What I took from it
Shared business logic is what makes a cross-platform product one product. The moment the app reimplements a rule, there are two products that merely look alike.
Sources and scope
Sources: the private repository's README, release notes and QA evidence, inspected September 2026. The screenshots come from the project's own test builds and show test data.
Screens
