Skip to content
mahadizulfiker
All work
Web app2025–2026SeloraX

Smart Sheba

Daraz-style multi-vendor marketplace with a wallet and a tree commission engine, built solo.

Sole author

A live multi-app platform shipped and maintained solo. (Architecture narrative, no user or financial data shown.)

A full Daraz-style multi-vendor commerce platform: vendor onboarding, catalogue, orders and fulfilment, an integrated digital wallet with a real transaction ledger, and a multi-level (tree) commission structure with a purpose-built frontend for modelling, tracing, and auditing payout hierarchies. Durable background workflows run on Inngest, with a deep backend integration into the SeloraX platform. Spans a customer app, a merchant dashboard, a super-admin, and a control-plane service. Sole author across backend and frontend.

Smart Sheba order and payout pathAn order writes to an append-only wallet ledger rather than a mutable balance field. A durable Inngest workflow then walks the multi-level tree commission structure and writes each vendor payout back to the same ledger.ORDERcustomer appWALLET LEDGERappend-onlyINNGESTdurable workflowPAYOUTvendorwalks treeTREE COMMISSIONSmulti-levelsettlesPOSTGRESsingle core
order to payout · accent marks the append-only write
Commission payouts per referral level, with the reconciliation total
levelsharepayout
L1 direct referrer%100.00
L2 second tier%62.50
L3 third tier%50.00
L4 fourth tier%37.50
platform remainder0.01
payouts + remainder = pool250.01 balanced

In integer minor units every share is floored and the remainder is assigned explicitly, so the ledger reconciles exactly, every time.

illustrative model of the payout rule · adjustable rates · no customer data

This is a client system, shown as an architecture narrative only: no source code, credentials, or user data are exposed.

Problem

A single product needed a storefront, a spendable wallet with a real transaction ledger, a health-card program, and separate operator tooling, normally several teams’ worth of surface area.

Constraint

One engineer; a wallet ledger has to stay correct and auditable under concurrency, where a naive balance update loses money.

Decision

Split the system into customer, dashboard, super-admin, and control-plane services over one Postgres core, and modeled the wallet as an append-only ledger rather than a mutable balance field.

Tradeoff

An append-only ledger is more code and more careful queries than a single balance column, but it is the only version that stays correct and auditable.

Result

A live multi-app platform shipped and maintained solo. (Architecture narrative, no user or financial data shown.)

next step

Open to full-time engineering roles.

I reply within a day.

Chat on WhatsApp