Afriva E-Commerce Platform

What problem was Afriva solving?

Multi-role e-commerce platforms tend to struggle with two things at once: role-based workflows and reliable delivery tracking. Afriva was designed around that pair of problems.

A marketplace is not one application. An administrator overseeing the catalogue, an operations manager clearing order queues, a seller updating stock and a buyer chasing a parcel all need different data, different permissions and different definitions of done. Bolting four jobs onto one generic storefront usually produces a compromise: sellers see admin tooling they cannot use, buyers get order status that is already stale, and operations staff fall back on spreadsheets to reconcile what the system cannot express.

The second half of the problem is delivery. In a multi-vendor model a single basket can split into several shipments from several sellers, each moving on its own timeline. Without a tracking layer that reflects that as it happens, support work rises and trust in the marketplace erodes. Afriva addresses both problems inside one product.

How are the four role dashboards structured?

Afriva has a dedicated dashboard for each of its four roles (admin, manager, seller and buyer), each built for a specific job rather than one shared screen with features hidden behind flags.

The seller dashboard is organised around inventory: listing products, adjusting stock and pricing, and following order status. The manager and admin dashboards are organised around order processing and oversight of the wider marketplace. The buyer side is organised around discovery, checkout and delivery tracking.

Separating the roles this way changes the shape of the codebase. Each dashboard should query only the slice of data its role is entitled to, which keeps payloads small and moves authorisation into the data layer instead of leaving it as an interface concern. It also means a change to seller tooling cannot quietly break the buyer checkout path.

The trade-off is duplicated layout and component work, which is why shared components and shared data-access helpers matter far more in a four-role product than in a single-role one.

Why Next.js 15 and server-side rendering for a marketplace?

Afriva is built with Next.js 15 on the App Router and uses server-side rendering for both speed and search visibility. For a marketplace those are the same goal. Product and category pages are how buyers arrive: if they render only in the browser, search engines and AI crawlers receive an empty shell, and a buyer on a slow connection watches a spinner where a price should be.

Server rendering puts real HTML in the first response, so the catalogue is indexable and the first useful paint does not wait for a JavaScript bundle to download and hydrate.

The App Router also lets the four dashboards share one deployment while keeping data fetching on the server, close to the database, rather than shipping query logic to the browser. Route-level segments map cleanly onto role-separated sections, and one framework serves both the public storefront and the signed-in back office.

How does Supabase back the marketplace data layer?

Supabase provides the data layer. Because it is managed PostgreSQL rather than a document store, the relational shape of a marketplace (vendors owning products, products appearing in orders, orders splitting into shipments) lives in the schema instead of being reassembled in application code on every read.

That matters in a multi-vendor model, where almost every query crosses an ownership boundary and almost every write has to respect one. Foreign keys and constraints give the platform a single authoritative place to express that a seller cannot change another seller's stock.

Supabase also bundles authentication with the database, so the identity that signs a buyer in is the identity Postgres sees on the query. In a product whose core problem is role-based workflows, keeping authentication and data in one system removes a whole class of drift between what the interface believes a user may do and what the database will actually allow.

How does real-time order tracking work?

Real-time order tracking is one of Afriva's core features, and it is a harder requirement than it sounds. A delivery status is written by one person (a seller marking an item dispatched, or a manager advancing a stage) and has to appear for someone else entirely, the buyer, without a refresh.

Polling, the default approach, works badly here: every open tracking page becomes a repeating query, and the polling interval is also the staleness the buyer sees. With Supabase as the source of truth, a status change is a row update in Postgres, and Supabase's realtime layer streams row changes over a websocket, so the buyer's tracking view can update from the same row the operations team just edited.

Because the record stays in the database rather than in a parallel message store, there is no reconciliation step and no window in which a dashboard and the database disagree about where a parcel is.

What does Redux Toolkit handle in the browser?

Redux Toolkit manages state in the browser, alongside Supabase for data. Sameem used it for the seller dashboard, where inventory, pricing and order status change while the seller is working. The split is deliberate: the database owns the canonical record, while Redux owns the state that exists only inside a browser session.

In a marketplace that state is substantial. A cart can hold items from several vendors and has to survive navigation across the catalogue. Filters, sort order and pagination on a category page are interface state that should not need a round trip. Dashboard tables carry selections, bulk actions and optimistic updates while a change is still being saved.

Redux Toolkit fits better than hand-written Redux because its slice pattern and bundled Immer support remove the boilerplate that makes large stores hard to maintain, and its built-in checks catch non-serialisable values that would otherwise break state restoration. With four dashboards in one deployment, a single predictable, inspectable state container is worth more than it would be in a single-screen application.

What engineering challenges does multi-vendor logistics create?

Multi-vendor logistics is where the platform's complexity concentrates, and three challenges follow directly from the model.

The first is concurrency on stock. With many vendors listing independently, the same item can enter several baskets at once, so stock decrements need to be atomic at the database level rather than read-modify-write in application code, which is a strong argument for keeping that transaction inside Postgres.

The second is order composition. One checkout can become several vendor orders with separate dispatch timelines, so the data model has to represent a parent purchase and its child shipments, then reassemble them into something a buyer can follow on screen.

The third is delivery itself. Shipments from different sellers can leave from different places on different schedules, so payment and delivery workflows have to be configurable per order rather than written as one hardcoded route.

Where can you see Afriva?

A demo build of the buyer-facing app runs at afriva-buyer.vercel.app; it shows how the storefront works, not trading activity.

Sameem worked on Afriva as an engineer at Webrange Solutions. The sections above cover the architecture: the four role dashboards, the server-rendered Next.js 15 storefront, the Supabase data layer and the real-time order tracking.

Why this stack

• Next.js 15 — server-side rendering was the deciding factor. A marketplace depends on its product and category pages being indexable, and SSR returns real HTML in the first response rather than an empty shell for crawlers and a spinner for buyers. The App Router also lets four role-separated dashboards ship from one deployment while keeping data fetching on the server, close to the database, instead of exposing query logic to the browser.
• Supabase — managed PostgreSQL, not a document store, which is the right shape for a multi-vendor domain where vendors own products, products appear in orders, and orders split into shipments. Relational constraints let ownership rules be enforced once in the schema instead of being reimplemented in every dashboard. Bundling authentication with the database means the identity that signs a user in is the identity the database sees on the query, which serves the platform's role-based workflows directly.
• Supabase Realtime — streams Postgres row changes over a websocket, which suits order tracking on two counts: it removes the repeating query every open tracking page would otherwise generate, and it removes the staleness window any polling interval builds in. Keeping the source of truth in the database rather than a parallel message store means there is nothing to reconcile between what a dashboard shows and what the database holds.
• Redux Toolkit — the marketplace carries real browser-only state: multi-vendor carts that survive catalogue navigation, category filters and pagination that should not cost a round trip, and seller dashboard tables with selections, bulk actions and optimistic updates in flight. The slice pattern and bundled Immer support strip the boilerplate that makes large stores hard to maintain, and serialisability checks catch values that would break state restoration, a useful safeguard when four dashboards share one store.