Case study: Hudood social platform

Hudood. A social world, built end to end.

A social-first platform for posts, profiles, reels, and conversations, with mobile, web, moderation, and an integrated finance layer.

Hudood Design, engineering & infrastructure · Team Zawish

Client work2024–2026In production

Project details

Year: 2024–2026
Role: Design · engineering · infrastructure
Status: In production
Stack: Flutter · Next.js · NestJS · PHP · MySQL · Redis · BullMQ · Firebase Auth · Azure Blob
Relationship: Hudood product design, application engineering, and infrastructure by ZAWISH.
Market: A community experience spanning social interaction and personal finance tools.

Platform tour

Meet Hudood, from the feed to the infrastructure.

Step through the product surfaces and see which simplified service boundaries support each feature.

Hudood public product website, desktop view — LIVE PUBLIC PRODUCT SITE / DESKTOP VIEW

HUDOOD / END-TO-END DELIVERY

From community identity to the services behind every interaction.

ZAWISH designed and built the mobile app, web experience, service layer, moderation tools, and infrastructure, integrating the established financial engine.

Visit Hudood ↗

Feed & posting · preview from the public product site

Previews from Hudood’s public site, not private-account captures.

Explore the services behind this feature

Scroll sideways to explore the enlarged map.

Read the components

The mobile app, web app, and admin console connect to the social API and finance engine. Shared data, a media-processing queue, and storage support those services.

Mobile app: Flutter
Web app: Next.js
Admin console: moderation
Social API: NestJS
Finance engine: PHP
MySQL: shared schema
Redis queue: BullMQ workers
Storage: Azure Blob

The problem

An entire social experience. One connected platform.

The product already handled Shariah screening, portfolios, and Zakaat tools. The next release needed social feeds, profiles, messaging, moderation, and mobile access without breaking the finance engine people already relied on.

ZAWISH made a Flutter mobile app, web experience, moderation console, and service layer that share identity and data with the existing product.

The system

How it fits together.

Scroll sideways to explore the enlarged map.

Read the components

The mobile app, web app, and admin console connect to the social API and finance engine. Shared data, a media-processing queue, and storage support those services.

Mobile app: Flutter
Web app: Next.js
Admin console: moderation
Social API: NestJS
Finance engine: PHP
MySQL: shared schema
Redis queue: BullMQ workers
Storage: Azure Blob

simplified public map of implemented components and boundaries

The build

How the new and existing services work together.

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

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 forced password migration for existing accounts.

Firebase → legacy adapter

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

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.

The case study shows product surfaces and a simplified architecture. It does not expose private administration data or claim public adoption metrics.

Start a project More work

Next caseAn audit engine for marketplace listings →