Skip to content
~/tariqul.islam
/projects

/projects/amazcart

2024–2026

Amazcart — multivendor e-commerce, owned end-to-end

client:
Spondon IT — CodeCanyon product
role:
Technical Project Manager
  • Laravel
  • Vue.js
  • MySQL
  • Redis

01 — the problem

What was actually at stake

Multivendor e-commerce is three products wearing one codebase: a storefront for buyers, a back office for vendors, and a control plane for the marketplace owner. Each pulls the roadmap in a different direction, and CodeCanyon buyers expect all three to be customizable without touching code.

02 — the architecture

How it was built

Vendor flows (onboarding, catalogs, commission ledgers, payouts) sit on their own module boundary, so marketplace logic can't leak into the storefront. The page builder I drove onto Amazcart (and InfixEdu) lets buyers compose storefront pages from blocks — the difference between “customizable” meaning a settings page and meaning it actually looks like their brand.

Payments ride the shared gateway layer, which is what lets one product sell into South Asia, the Gulf, Africa, and Latin America without forking. As TPM I owned the roadmap, the release gates, client escalations — and the code, when a release needed rescuing.

architecture — at a glance
boundaries
storefront / vendor office / owner control plane
page builder
block-based storefront customization
payments
shared 20+ gateway layer
delivery
TPM-owned: roadmap → release → escalation

03 — the visuals

What it looks like

Illustrated architecture overview of Amazcart — multivendor e-commerce, owned end-to-end
fig. 01 — /projects/amazcart/cover

screenshot pending (NDA-safe crop)

drop /public/images/projects/amazcart/01.jpg · 1600×900 · see docs/images.md

fig. 02 — screenshot, primary view

screenshot pending (NDA-safe crop)

drop /public/images/projects/amazcart/02.jpg · 1600×900 · see docs/images.md

fig. 03 — screenshot, detail view

04 — from the codebase

Commission resolved per vendor agreement, not hardcoded

Commission resolved per vendor agreement, not hardcoded
public function settle(Order $order): void
{
    foreach ($order->vendorSplits() as $split) {
        $agreement = $this->agreements->for($split->vendor);

        // category overrides > vendor rate > marketplace default
        $rate = $agreement->rateFor($split->items);

        $this->ledger->credit($split->vendor, [
            'order_id' => $order->id,
            'gross' => $split->subtotal,
            'commission' => $split->subtotal * $rate,
            'rate_version' => $agreement->version(),  // disputes replay this
        ]);
    }
}

05 — the outcome

What the numbers say

storefront · vendor office · control plane
3-in-1
page-builder customization, no code
blocks
markets via the shared gateway layer
global

The product a TPM gets judged on first — shipped on cadence, escalations included.

/projects/amazcart/next

Need something in this neighborhood?

If this case study sounds like your problem — same domain, same scale, same kind of mess — I've already made the expensive mistakes for you. Tell me where you're stuck.