A production multi-vendor marketplace, built end to end.
Lakaz Fresh is a live marketplace we designed, built and operate: a customer storefront, a seller portal and an operations console over one transactional core, with scheduled fulfilment, split orders across independent sellers, and an AI assistant wired into the domain layer.
01The hard parts
A marketplace is not a store with more sellers.
Once independent sellers share a basket, the difficulty moves underneath the interface. These are the problems the build actually solved.
Multi-vendor catalogue
One canonical product, many independent sellers, each with its own price, units, variants and stock. Offers are compared at read time and resolved per seller, not flattened into a single listing.
Transactional inventory
Stock and delivery capacity are committed inside one database transaction, with rows locked in a fixed order to avoid deadlocks under concurrency. Uncommitted holds expire and return to inventory on their own.
Geospatial fulfilment
Coordinate-based delivery targets, per-seller road-distance quoting against a mapping provider, a graceful fallback when that provider is unavailable, and served-area enforcement at both quote and commit time.
Split order orchestration
A single order fans out into per-seller fulfilments with independent state machines, then reconverges into one delivery. Every transition is single-step and validated at one choke point.
02Data model
Products and offers are separate entities.
Most commerce platforms model a product as a thing one merchant sells. A marketplace cannot, because the same product exists once and is sold many times over. Splitting the canonical product from each seller’s offer is what makes comparison, ranking and per-seller fulfilment possible without duplicating the catalogue.
- Canonical products carry identity, media and category; offers carry price, units, variants and stock
- Variant-level pricing and stock, tracked or explicitly untracked per offer
- Offer comparison resolved at read time with seller metadata attached
- Baskets, orders and fulfilments all key on the offer, so the seller is never ambiguous
03Three surfaces, one core
Every role gets its own application.
Customers, sellers and operators have incompatible needs and incompatible permissions. Each runs as its own application against a shared domain layer, with access enforced on the server.
- 01
Customer storefront
Catalogue, faceted search with server-side filtering and sorting, autocomplete, seller storefronts, persistent basket, and a checkout that quotes fulfilment live before commit.
- 02
Seller portal
Listing management with variants, media and stock, an order queue with its own state transitions, order line editing with an audit trail, earnings with exportable ledgers, and role separation between owner and staff.
- 03
Operations console
A cross-seller dispatch board, capacity administration, seller onboarding and moderation, plus a routing view with an interactive map, manual stop ordering, and a confirm-by-gesture completion flow.
04The customer application
Written by hand, with no framework and no build step.
The storefront is plain HTML and JavaScript with a shared runtime, server-rendered search and filtering, layout-matched loading states, and a light and dark theme. It ships without a bundler, which keeps the deploy simple and the payload small.
05Engineering
What the build actually required.
Concurrency under contention
Capacity and inventory are claimed in a single transaction with deterministic lock ordering, so two buyers competing for the last unit or the last delivery slot resolve correctly instead of overselling.
Capacity scheduling
Configurable service windows with per-window limits, lead time and cut-off arithmetic in a fixed local timezone, and a rolling booking horizon, all enforced server side rather than in the interface.
AI with real write access
A tool-calling assistant wired to the same domain layer as the interface, spanning customer, seller and operations roles, with every state-changing action gated behind an explicit confirmation step.
Document generation
Order confirmations, packing slips and receipts rendered as real print documents and attached to transactional mail, produced without pulling in a heavyweight rendering dependency.
Media pipeline
Uploads verified by inspecting file contents rather than trusting the declared type, addressed by content hash so re-uploads deduplicate, and served through a CDN.
Built to stay cheap to run
A hand-written front end with no framework and no bundler, a small dependency surface, and a single shared host, so the running cost of the platform stays proportionate to the business on it.
06Stack
What it runs on.
Runtime
Data
Cloud
Integrations
AI
Delivery
07Beyond the build
We run it, not just ship it.
Lakaz Fresh is not a prototype we handed over. We own the infrastructure, the deploys, the monitoring and the operational tooling the business runs on every day, which is the same way we work on client platforms.
That includes the parts nobody demos: capacity administration, exception handling when a delivery cannot be met, order corrections with an audit trail, and the reporting an operator needs to keep the marketplace moving.
Infrastructure and deploys
Provisioned, deployed and monitored by us, with observability wired in from the start.
Operations tooling
The console operators use daily, built alongside the product rather than bolted on later.
Exception paths
Cancellations, order edits and repricing handled as first-class flows with a full trail.
FAQ
Questions, answered
Anything we have not answered here, ask us directly. A senior engineer replies.
What is Lakaz Fresh?
A production multi-vendor marketplace that Dude Lemon designed, built and operates. It is a working reference for the class of system we deliver: independent sellers over a shared catalogue, transactional inventory, scheduled fulfilment, and separate applications for customers, sellers and operators.
What makes a marketplace harder to build than a store?
A store owns its inventory; a marketplace does not. The same product is sold by many sellers at once, so products and offers have to be separate entities, a single basket has to split into per-seller fulfilments, and inventory and delivery capacity have to be committed together without overselling when several buyers compete for the same unit.
How do you handle inventory and capacity under concurrency?
Stock and delivery capacity are claimed inside one database transaction with deterministic lock ordering, so simultaneous orders resolve correctly rather than overselling. Holds that are never completed expire and return to inventory automatically.
How is scheduled delivery modelled?
Configurable service windows carry per-window limits, with lead time and cut-off arithmetic in a fixed local timezone and a rolling booking horizon. Booking is enforced server side inside the same transaction as the order, so a full window cannot be double booked.
What does the AI assistant actually do?
It is a tool-calling assistant wired into the same domain layer as the interface, working across customer, seller and operations roles. It can complete real tasks rather than only answer questions, and every action that changes data is gated behind an explicit confirmation step.
Can you build a marketplace like this for us?
Yes. Marketplaces, multi-tenant platforms, scheduled fulfilment and operations tooling are core work for us, and we can take it from architecture through to running the platform in production. Tell us what you are building and we will scope it.
Do you operate what you build?
We can. Lakaz Fresh runs on infrastructure we provision, deploy and monitor, and the same model is available on client engagements where you want one team accountable for the platform rather than a handover.
The Dude Lemon suite
More software that works for you.
Every product in the suite is designed, built and run by the same team, to the same engineering standard.
Talk to our team
Building a marketplace?
If you need independent sellers, real inventory, scheduled fulfilment and an operations team that has to run it every day, this is the class of system we build and operate.