Case study — Community + finance platform

A community platform with an integrated finance layer

Mobile app, web app, and moderation console for a social community — sharing one backend with Shariah-compliant stock screening, portfolios, and Zakaat tools.

Year
2024–2026
Role
Design · engineering · infrastructure
Status
In production
Stack
Flutter · Next.js · NestJS · PHP · MySQL · Redis · BullMQ · Firebase Auth · Azure Blob
Relationship
Selected delivery work; the public case uses a functional project name.
Market
Client identity and market are withheld from the public case.

The problem

Two products, one audience, zero shared code.

The client had a proven finance product — Shariah stock screening, portfolios, Zakaat tools — running on a mature PHP engine, and a vision for a social community around the same audience. Rebuilding finance from scratch was off the table; bolting a forum onto PHP was too.

The brief: ship a modern, mobile-first social experience — feed, reels, messaging, profiles — that shares users, auth, and data with the existing finance system, without freezing either side's roadmap.

The system

How it fits together.

Mobile appFlutterWeb appNext.jsAdmin consolemoderationSocial APINestJSFinance enginePHPMySQLshared schemaRedis queueBullMQ workersStorageAzure Blob

simplified public map of implemented components and boundaries

Platform tour

Walk the product, watch the backend.

Step through the features — the architecture map below lights up the exact services each one runs on. Nothing here is a mockup of a plan; the public map is intentionally simplified.

Feed & posting — captured from the live Hudood product site
Reels & media — captured from the live Hudood product site
Finance hub — captured from the live Hudood product site
Stock screener — captured from the live Hudood product site
Portfolio & Zakaat — captured from the live Hudood product site
Moderation consoleinternal admin surface — not publicly viewable

captured live from the Hudood web experience

live architecture map — the highlighted nodes serve the selected feature

Mobile appFlutterWeb appNext.jsAdmin consolemoderationSocial APINestJSFinance enginePHPMySQLshared schemaRedis queueBullMQ workersStorageAzure Blob

The build

The hard part was the bridge.

01

One database, two owners

The legacy PHP system owns users and financial records; the new NestJS service owns the social tables — on the same MySQL instance. All schema changes flow through one migration path so both backends share the same definition of the data.
MySQL 8 · Phinx · TypeORM
02

An auth bridge across generations

Social accounts authenticate through Firebase; the finance engine expects its own legacy credentials. A bridge verifies Firebase tokens and maps them onto existing user rows — one login, both worlds, no password migration forced on thousands of users.
Firebase → legacy adapter
03

Media work stays off the feed request path

Reels and image posts enqueue into Redis; BullMQ workers transcode, generate thumbnails, sweep orphans, and fan out push notifications. The API responses stay focused because heavy media work runs outside the request path.
Redis · BullMQ · Azure Blob
04

Three surfaces, one contract

Flutter mobile, Next.js web, and a React moderation console all speak to the same API line behind one reverse proxy — routes, scopes, and deploy targets defined once.
Caddy · Docker Compose

Implementation evidence

3 surfacesmobile, web, and administration working against shared services
Shared schemalegacy and new services coordinated around one data model
Async mediaqueued processing separates user actions from heavier work

Constraint

A new service layer had to coexist with a legacy finance engine and a shared data model.

Tradeoff

The architecture preserves working legacy logic while new product surfaces move onto a typed API and queued workers.

Public evidence is limited to approved screens, system boundaries, and implementation details; client and commercial results are not asserted.

For your business

Discuss a related system.

If your business runs on a legacy system that works but can't carry the next product — this is the playbook: keep the engine, build the modern surface, bridge auth and data properly. We've done it in production, mobile app included.

Next caseAn audit engine for marketplace listings →