ZPONZ
Expert Marketplace, Wallet & CMS Platform
Problem
Experts monetizing their time and content need three things working together: a public storefront to be discovered, a way to get paid reliably (including holding funds in escrow until a session completes), and an admin layer for the platform operator to manage the whole marketplace. Building each in isolation is easy — making them share one consistent data model and page-building system is the hard part.
Architecture
The page-builder architecture is the core reusable primitive: master components define layout configurations, and pages are composed from ordered schema sections rather than hand-coded templates — the same builder powers the expert landing site, the advertisement dashboard, and the admin CMS. Wallet workflows sit behind Stripe, modeling deposits, withdrawals, and transfers as ledger entries, with an escrow/locked-balance state so funds tied to an in-progress engagement are not withdrawable until release. Onboarding uses DNS verification flows for experts publishing under their own presence, and Cloudinary handles media assets. Real-time layer: Socket.IO pushes in-app events, Firebase Cloud Messaging (FCM) covers mobile/background notifications, and an AWS S3/CloudFront pipeline distributes media at low latency.
Trade-offs
Modeling the wallet as ledger entries (rather than mutating a single balance field) makes every state change auditable and makes escrow trivial to express — a locked entry simply isn't counted in the withdrawable balance — at the cost of computing balances by aggregation instead of a single read. Reusing one page-builder schema across three surfaces (landing site, ad dashboard, admin CMS) meant more upfront design work on the schema shape, but it eliminated three separate rendering systems that would otherwise drift out of sync.