DEV3 Shipdrop – Multi-Tenant Dropshipping SaaS with Supplier Network, Order Routing & Payouts (Next.js)

A self-hosted multi-tenant dropshipping platform on Next.js 16 and MongoDB: a shared supplier network, order routing across suppliers, a margin guard, merchant payouts and supplier statements. Merchants get storefronts on subdomains or custom domains. Setup wizard and demo data included.

by DEV3 TechnologiesVerified Author(0) 0 sales 0 viewsUpdated 05 Nov 2026

Video tour. Pick a section below to browse 110 screenshots in 11 sections.

App & phone tours

Tap play to watch each app. Nothing downloads until you do.

  • Mobile web0:59

Shipdrop is a multi-tenant dropshipping platform that you host yourself, built by DEV3 Technologies on Next.js 16, React 19, TypeScript, Tailwind 4 and MongoDB. Merchants import products from a shared supplier network, sell on their own storefronts, and the platform routes every paid order to the right suppliers, collects the money, pays suppliers, takes its fee and pays the merchant the rest. The demo shows a fictional network of suppliers and merchants.

No live demo: 110 grouped screenshots and two video tours show the marketing site, merchant dashboard, routing, money screens, storefronts, supplier order page and the super-admin console. Install it with the demo data to try every role on your own server. This product is a web application: there are no mobile apps.

For merchants

  • A network catalogue with filters for category, supplier country, cost, lead time and rating, a margin calculator on every product, one-click and bulk import, and private suppliers that only your store can see.
  • Price rules: markup, charm endings, a minimum margin and a floor at the supplier's minimum advertised price. When a supplier's cost rises, the rule reprices, pauses that source until you confirm, or only warns you.
  • A dashboard with revenue, profit, margin, open supplier orders and late acknowledgements, a margin review queue that holds low-margin orders until you approve them, and a needs sourcing queue for lines no supplier could fill.
  • Refunds by line or amount with a fault setting that decides who bears the cost, and a clear explanation of how money settles: pending, available, then a payout request.
  • A storefront with three look presets, pages, navigation, shipping and tax rules, a cart drawer with discount codes, a tracking page that never names the supplier, a paused-store page, a subdomain plus verified custom domains, and a fully mirrored Arabic storefront.

Routing and stock

  • When an order is paid, the planner picks a source for every line and creates one supplier order per supplier. Modes are priority, cheapest landed cost or fastest, with a tolerance that prefers a supplier already on the order.
  • A rejected or silent supplier is replaced automatically, twice, before the line waits in the sourcing queue, where you can retry, choose a source or refund. After a deadline (five days by default) the line is refunded.
  • A route simulator on the marketing site runs the real planning code on a demo basket.
  • Stock is shared across tenants and reserved with a journal row first, so a crash cannot lose or double-release a unit. Supplier feeds (JSON, CSV, simulated or pushed to a signed endpoint) apply in sequence order, and a file with more than 30 percent invalid rows is rejected whole.

Suppliers and the platform

  • Suppliers are not users: each has a signed order page where it acknowledges, rejects (which reroutes the order automatically) and ships with tracking, plus its weekly statement of shipped orders minus fault credits.
  • A super-admin console with MRR, plan mix, GMV by tenant and domain health, tenant detail with impersonation, suspend and pause controls, supplier feed health and delisting (warns each affected merchant once and leaves open orders running), sync runs, statements, merchant payouts, disputes, plans and an audit log.
  • An append-only merchant ledger with a unique key per entry, so every posting is retry-safe, and a ledger check that proves the platform float balances.
  • A REST API and webhooks on the top plan, with an OpenAPI 3.1 description and scoped keys.

What is included

  • The Next.js application source with the shared DEV3 core vendored under packages/next-core, an .env.example, seed and scheduled-job scripts, unit and browser test suites, HTML documentation, a licence and a START-HERE file.
  • A setup wizard that checks your server, creates the super-admin and optionally loads demo data: 886 network products with 1,894 variants, 3,862 orders, 5,910 supplier orders, 850 customers, 287 refunds, 57 payouts and 315 statements.
  • English with a mirrored Arabic storefront, light and dark themes. Nothing calls a paid service by default.

Good to know

  • Installing the demo takes about 30 seconds, and longer on a busy or small server, because the whole demo dataset is built in one request when the wizard's demo box is ticked. The wizard says so. Untick it for an empty install, or run npm run seed from the command line.
  • Supplier routing has rare race edge cases. Every state change is a conditional update, so two racing calls give one outcome, and the stock, ledger and refund paths are tested in parallel. A few narrow cases are known: a refund landing at the same instant as routing can double-shrink a stock hold or leave one unit ordered; if a supplier acknowledges in the same millisecond as an unwind, that unit's unwind is dropped without a retry; refunding units that are still queued for sourcing unwinds covered units of a split line first; shrinking a supplier order recomputes shipping from the supplier's current rates; and a reroute that runs longer than its five-minute lease can overlap a repair (the keys prevent a second order or a double posting). Check the list against your volumes.
  • Two smaller gaps: a draft supplier order whose stock re-reserve fails stays a draft, and the platform's own fees are booked in the store's currency while the usage meter counts US dollars.
  • Payments are simulated by default. Live gateway drivers were not run against real accounts. Run your own sandbox payments first. Email goes to an admin Outbox until you set up a mailer, and supplier feeds are simulated until you connect real ones.
  • Currency: USD and EUR use a small editable rate table, not live exchange rates.
  • Scheduled jobs are yours to run. Supplier sync, order sweeps, balance release, supplier settlement and billing jobs are npm scripts that you schedule with cron or your host.
  • You need a long-running Node process and MongoDB 6 or newer (a replica set is recommended; a single node works). Custom domains need an HTTPS front proxy such as Caddy and DNS you control. Redis is not needed.
  • The REST API is on the top plan only.
  • Name: Shipdrop is a working name checked by a web search only, not a trademark clearance. Check it before you launch under it.
  • No hosted demo. All suppliers, merchants and shoppers in the screenshots are fictional.

Quality checks

Shipdrop 1.0.0 passed the seven checks of the DEV3 Next.js suite on the final code: type-checking and linting (0 errors), 238 app tests and 49 core tests, a production build of 153 routes with 208.0 KB of gzipped first-load JavaScript and CSS on the home page, seeding of the empty and demo datasets, a headless-browser pass over 176 routes and 18 happy paths (including parallel-request races for the last unit across two stores, same-key checkouts and acknowledge against reject), an install test from the packaged zip (npm ci, build, setup wizard, admin login) and a secret scan. Payout and refund races run as parallel service calls in the unit tests, not over HTTP. Lighthouse scores were not measured.

How it's built

Architecture, stack, key decisions and the quality gates DEV3 Shipdrop passed before release.

The engineering behind Shipdrop: a pure routing planner, stock held by journalled reservations, conditional state transitions and an append-only ledger, with the known edge cases written down.

The problem it solves

Dropshipping looks like a shop until an order has to be split. One paid order may need three suppliers, each with its own stock, minimums and shipping rates. Stock is shared by every store, so two shops can buy the last unit at the same moment. Suppliers reject, go silent or ship late, and the order must be rerouted without charging the customer twice or losing the money trail. The platform holds the cash, so every cent must be traceable to a merchant balance, a supplier payable, a fee or a payout, and a refund must say who bears the cost. Each of those steps can be retried or raced.

Architecture and approach

Shipdrop is a Next.js 16 application on MongoDB with a shared DEV3 core for auth, billing and tenancy. Stores are tenants: a Mongoose plugin scopes every query by an immutable organisation id and fails closed, cross-tenant code lives only in the platform folder and scripts, and a unit test greps for violations.

A pure routing planner

The planner takes a basket and the candidate sources and returns a plan: priority, cheapest or fastest, with a tolerance that prefers a supplier already on the order and supplier minimums that move a line or send the order to review. It is pure, so 24 routing vectors run in unit tests.

Stock is held before it moves

A reservation writes a journal row first, then updates the stock count and the hold in a single update. A crash is recoverable and a release is exactly-once. Feeds apply in sequence order and never touch reserved stock.

Conditional transitions

Every supplier order state change is a conditional update, so two racing calls produce one outcome. A reject or time-out sets a reroute-pending marker in the same update, a lease prevents two workers rerouting at once, and the hourly acknowledgement job repairs anything left pending.

An append-only ledger

Merchant postings carry a unique key per entry, which makes every retry safe. A ledger check compares each balance with the sum of its entries and prints the platform float. Refunds by fault decide whether the supplier order shrinks, the merchant bears the cost or the supplier earns a credit on its next statement.

Quality gates and results

Shipdrop 1.0.0 passed its seven checks on the final code: 238 app tests and 49 core tests, a 153-route production build with 208.0 KB gzipped first-load JavaScript and CSS on the home page, 176 routes and 18 happy paths in a headless browser, an install test from the packaged zip and a clean secret scan. The demo dataset holds 886 network products, 3,862 orders and 5,910 supplier orders.

Remaining edge cases are written down on the item page: a few rare race windows in refunds and rerouting, a draft whose stock re-reserve fails, and fees booked in the store currency.

Tech stack

Area Technologies
Application Next.js 16 App Router, proxy.ts host routing, Server actions, React 19, TypeScript
Tenancy Mongoose tenant plugin, Immutable orgId, Fail-closed queries, Impersonation with audit
Dropshipping Pure routing planner, Journalled stock reservations, Feed sync, Margin guard, Supplier order pages
Money Append-only ledger, Retry-safe postings, Payouts and statements, Ledger check
Frontend Tailwind CSS 4, three.js route board, Theme presets
Quality Vitest unit suites, Routing vectors, Browser smoke script, Install-from-zip test

Inside the build

Margin calculator: Pick a markup and see profit per unit after fees. Margin calculator — Pick a markup and see profit per unit after fees.

Dark mode: The same landing page on the ink theme. Dark mode — The same landing page on the ink theme.

Guides & articles

Practical guides and engineering write-ups for DEV3 Shipdrop.

Dropshipping platform software: 7 things to check before you pick one

Last updated
Dropshipping platform software: 7 things to check before you pick one: DEV3 Shipdrop

The hard part of dropshipping is not the storefront. It is what happens after the customer pays. Here are seven things to check before you pick a platform, with DEV3 Shipdrop as the worked example.

Shipdrop landing page with the route simulator

1. Is stock shared safely?

If several shops sell from the same supplier stock, two shoppers can buy the last unit in the same second. Shipdrop writes a journal row before it holds stock, so a crash cannot lose or double-release a unit.

2. Can one order go to several suppliers?

A paid order should be split into one supplier order per supplier, with a clear rule (priority, cheapest or fastest). Shipdrop also lets you try the real planner on a demo basket before you sign up.

The route simulator running the planning code on a demo basket

3. What stops a bad margin?

Supplier costs change. Shipdrop reprices, pauses that source until you confirm, or only warns you, and holds low-margin orders in a review queue.

4. What happens when a supplier says no?

A rejected or silent supplier should be replaced automatically, and lines nobody can fill should wait in a queue you can act on. After a deadline the customer is refunded.

5. How do suppliers interact?

Suppliers should not need accounts. Each one gets a signed order page where it acknowledges, rejects or ships with tracking.

A supplier's order page: acknowledge and ship

6. Can you trace every cent?

Look for an append-only ledger and a check that the platform float balances. Shipdrop's postings are retry-safe, and refunds record whose fault they were.

7. What is not finished?

Ask for the limits in writing. For Shipdrop: the demo install takes about 30 seconds and longer on a loaded server, and supplier routing has rare race edge cases that are listed on the item page.

Margin review queue: orders held until you approve or cancel

Video tour of Shipdrop

Frequently asked questions

The complete source code (version 1.0.0) as a download from your account, with the setup and usage guides shown on this page. You can modify the code to suit your product.

More from this author

View all

Related in Enterprise SaaS Starters

View all