HANZO B2B Marketplace

Buyers in East Africa sourcing goods from Chinese manufacturers work through a chain of intermediaries. Each layer adds cost and removes visibility, and the relationships that matter — who the factory actually is, what the real unit price is — stay deliberately opaque.

A marketplace that simply exposes factory contact details solves the buyer's problem by destroying the platform's. The engineering problem was to make sourcing direct and structured without making the platform disintermediable.

HANZO serves three distinct user types with genuinely different needs and permissions: buyers browsing and purchasing, factories managing catalogues and responding to orders, and platform administrators overseeing the whole marketplace. Buyers span multiple countries and currencies; factories operate in a different language and time zone from the people buying from them.

I owned the system end to end: architecture, database design, the Next.js frontend, the Laravel API behind it, the three dashboards, payment workflows, cloud deployment and ongoing maintenance.

Privacy as an architectural constraint, not a feature

The separation between buyer and factory is enforced at the data layer rather than hidden in the UI. Factory contact details, buyer identity and platform margins live behind role scoping, so no client-side request can assemble the relationship the platform exists to broker. This constraint shaped the schema before any interface was drawn.

Split frontend and API rather than a single application

A Next.js frontend against a Laravel REST API costs more setup than a monolith. It was worth it here because three dashboards with three permission models are far easier to reason about when authorisation lives in one place on the server, and because the buyer-facing catalogue benefits from a rendering layer the admin tooling does not need.

Multi-currency handled at the data layer

Currency and language are properties of the request, not of the page. Prices resolve server-side so that a buyer, a factory and an administrator looking at the same order see consistent figures in their own units.

• Separate buyer, factory and administrator dashboards, each with its own permission model
• Product catalogue with management, cart, checkout and order tracking
• Multi-language and multi-currency operation
• Payment integration and platform analytics
• Privacy architecture protecting factory contacts, buyer data and platform margins

Three dashboards, one codebase

Role-specific interfaces tend to fork into three near-duplicate applications that then drift. Shared components with role-scoped data fetching kept the surface area to one codebase; permission checks stay on the API rather than being reimplemented per dashboard.

Catalogue scale against usable browsing

A sourcing catalogue is only useful if buyers can narrow it quickly. Search, category filtering and structured product attributes were designed into the schema rather than bolted on, which keeps filtering a database concern instead of a client-side one.

The platform runs on cloud infrastructure with the frontend and API deployed separately, environment configuration held outside the codebase, and Git-based deployment. I continue to maintain it — updates, monitoring and the operational work that follows launch.

HANZO is live at hanzo.co.tz and operating as a working marketplace: buyers browse and order, factories manage catalogues, administrators oversee the platform, and the privacy boundary the business depends on holds.