Small 3PL Multi-Client Billing & Inventory

What it is: a web app for a small contract warehouse that stores goods for several client businesses. It keeps every client's stock separately counted, lets warehouse staff log stock coming in and going out from a phone, and automatically prints each client a correct monthly bill for storage and handling — with Malaysian SST already applied correctly.

Who should buy it: the owner or operations manager of a small contract warehouse or logistics-park unit storing goods for 1–15 separate client businesses. Today they likely track this in spreadsheets, one tab per client, and calculate each client's bill by hand at month-end.

The problem it solves

• Client A's and Client B's stock get mixed up in a shared spreadsheet, and counts drift from what's physically on the shelf.
• Billing a client correctly (how many pallets, for how many days, how many orders picked) is manual arithmetic redone every month, and mistakes either undercharge the warehouse or anger the client.
• None of the off-the-shelf warehouse software built for this exact "small 3PL" category (it exists — PackemWMS, Fulfillor, GOIS, MetaWMS are real products) bills in Ringgit with SST line items, so a Malaysian operator is stuck adapting a US-priced tool or staying on spreadsheets.

Main selling points

• Every client's stock is walled off automatically — staff can't accidentally pick Client A's box for Client B's order.
• The monthly invoice for each client generates itself from what actually happened in the warehouse that month, with SST already correct.
• Built for Malaysia from day one: Ringgit pricing, SST-compliant invoice line items, a price point sized for a 1–15 client operator rather than a US enterprise tool.

Two flows matter most when pitching: how a new warehouse gets started, and the loop they run every single day once they're live.

Getting a new warehouse started

flowchart LR
  A[Owner signs up] --> B[Add each client
and their billing rate]
  B --> C[Import existing stock
via spreadsheet]
  C --> D{Stock counts
match a physical count?}
  D -- yes --> E[Go live]
  D -- no --> F[Reconcile the mismatch
with warehouse staff]
  F --> D
    

The daily loop, once live

flowchart LR
  R[Stock arrives
for a client] --> S[Staff scans it in
on phone]
  S --> T[(Inventory,
per client)]
  O[Order comes in
from a client] --> P[Staff picks & packs
scanning each item]
  P --> T
  T --> M[End of month]
  M --> N[Invoice auto-built
per client, with SST]
  N --> X[Owner reviews & sends]
    

Customer onboarding, step by step

1. Owner signs up and adds each of their clients, with that client's agreed storage/handling rate.
2. Existing stock is imported from whatever spreadsheet they already keep — we don't ask them to re-type anything.
3. A physical stock count confirms the imported numbers match what's on the shelf (this is the step most likely to surface disputes or data-entry errors, budget real time for it).
4. Warehouse staff get a 15-minute walkthrough of scanning stock in/out on their phones.
5. First monthly invoice is generated and reviewed together with the owner before it goes to their client, to build trust in the numbers.

Expected delivery timeline

9–11 weeks from a confirmed pilot customer to a working MVP in their hands, assuming: the founder works on this full-time, the barcode-scanning flow stays web-based (no native app) for v1, and the pilot customer's stock data is importable from a spreadsheet rather than another system. If any of those assumptions break, add 2–4 weeks.

Limitations to set expectations on, before a pilot starts

• One warehouse location at launch — a client with two sites needs two separate accounts for now.
• Scanning works in a phone's web browser camera; it is not as fast as a dedicated barcode-scanner gun. Fine for a small warehouse, worth flagging for a high-volume one.
• Clients don't get their own login to check stock themselves at launch — the warehouse operator is the only login. (P1 feature.)

User roles

Key business rules

• Every inventory row belongs to exactly one client_id under one operator_id — no inventory item is ever shared or ambiguous between clients.
• An invoice line is generated from immutable movement/storage records for that billing period — never from a hand-edited number — so the invoice is always reconstructable and auditable.
• SST (currently 6% service tax on applicable storage/handling services — assumption verify current rate and applicability with an accountant before launch, tax rules are not this founder's expertise) is calculated per invoice line, not as one lump sum, so the PDF matches what LHDN expects to see itemized.
• Stock can't be picked for an order if it doesn't exist in that client's recorded inventory — the system should block, not just warn, since this is the exact error that causes billing disputes.

Core value proposition (one line)

Stock never gets mixed up between clients, and the bill writes itself from what actually happened — instead of a spreadsheet and an evening of manual math every month.

Minimum Sellable Product

One warehouse operator account, their clients and rates, phone-browser receiving/picking tied to each client, and one correct auto-generated SST-compliant invoice at month-end. If a pilot customer can run one real month through this and trust the invoice, the MSP has done its job.

Feature prioritization

A modular monolith on managed infrastructure — there is no load or team-size reason to run separate services here, and every extra moving part is extra 2am pages for a solo developer.

flowchart TB
  subgraph Client["Client devices"]
    PWA["Phone browser
(scan in/out)"]
    Desk["Desktop browser
(owner: billing, setup)"]
  end
  subgraph App["Next.js app, deployed on Vercel"]
    UI[Server-rendered pages + API routes]
    Auth[Auth.js session layer]
    Jobs["Monthly invoice job
(Vercel Cron)"]
  end
  subgraph Data["Managed Postgres (Supabase/Neon)"]
    DB[(Relational data:
clients, inventory,
movements, invoices)]
    Storage[(File storage:
generated invoice PDFs)]
  end
  PWA -->|HTTPS| UI
  Desk -->|HTTPS| UI
  UI --> Auth
  UI --> DB
  Jobs --> DB
  Jobs --> Storage
  UI --> Storage
    

Recommended stack

Security, monitoring, backups

• Every data query scoped by operator_id at the query layer (and enforced again with Postgres row-level security as a second line of defense) — a bug in one query must never leak one operator's data to another's session.
• warehouse_staff accounts cannot reach billing/rate endpoints at the API layer, not just hidden in the UI.
• Managed Postgres host's automatic daily backups are sufficient at this scale; verify point-in-time recovery is enabled before the first paying customer's real data goes in.
• Basic uptime/error monitoring (e.g. a free-tier error tracker) wired in from week one — a solo founder finds out about a broken invoice job from a dashboard, not from an angry phone call.

The customer-facing journey and onboarding flows are in Document A §A·2. These four cover roles, money, and admin.

User roles & permissions

flowchart TD
  U[Incoming request] --> Role{Which role?}
  Role -->|operator_owner| Full[Full access:
clients, rates, staff,
invoices, exports]
  Role -->|warehouse_staff| Scoped[Scan stock in/out only]
  Role -->|client_viewer, P1| ReadOnly[Read-only: own stock
+ own invoices]
  Scoped -.blocked.-> Billing[/Billing & rate endpoints/]
  ReadOnly -.blocked.-> Billing
    

Subscription & payment

flowchart LR
  Signup[Operator signs up] --> Setup[One-time RM2,500
setup fee invoiced]
  Setup --> Active[Account active,
RM349/mo billed]
  Active --> Grow{Client count
exceeds plan tier?}
  Grow -- yes --> Upgrade[Move to next
pricing tier]
  Grow -- no --> Active
  Active --> Fail{Monthly payment
fails?}
  Fail -- yes --> Grace[7-day grace period,
email reminder]
  Grace --> Suspend[Account read-only
if unresolved]
  Fail -- no --> Active
    

Core operation detail: receive → pick → bill

sequenceDiagram
  participant Staff as Warehouse staff (phone)
  participant App as App
  participant DB as Database
  Staff->>App: Scan incoming item for Client A
  App->>DB: insert movement(type=in, client_id=A)
  Staff->>App: Scan item picked for Client A's order
  App->>DB: insert movement(type=out, client_id=A)
  Note over DB: End of billing period
  App->>DB: aggregate movements + storage-days per client
  App->>App: apply client A's rate card + SST
  App-->>Staff: (owner) reviews draft invoice
    

Administrative workflow

flowchart LR
  Owner[Operator] --> AddClient[Add new client
+ rate card]
  Owner --> AddStaff[Add staff account]
  Owner --> ReviewInv[Review draft invoice
before sending]
  ReviewInv --> Edit{Dispute or
correction needed?}
  Edit -- yes --> Adjust[Add a manual
adjustment line, logged]
  Edit -- no --> Send[Mark sent, export PDF]
  Adjust --> Send
    

Multi-tenancy here is two levels deep: the operator is the paying tenant, and each operator's clients are a second, nested scope. Every inventory and billing row must carry both IDs, and every query must filter by both.

erDiagram
  OPERATOR ||--o{ STAFF_USER : employs
  OPERATOR ||--o{ CLIENT : stores_for
  CLIENT ||--o{ RATE_CARD : has
  CLIENT ||--o{ SKU : owns
  SKU ||--o{ MOVEMENT : tracked_by
  CLIENT ||--o{ INVOICE : billed
  INVOICE ||--o{ INVOICE_LINE : contains
  RATE_CARD ||--o{ INVOICE_LINE : priced_by

  OPERATOR {
    uuid id PK
    text company_name
    text subscription_tier
  }
  STAFF_USER {
    uuid id PK
    uuid operator_id FK
    text role
  }
  CLIENT {
    uuid id PK
    uuid operator_id FK
    text name
  }
  RATE_CARD {
    uuid id PK
    uuid client_id FK
    numeric storage_rate_per_pallet_day
    numeric handling_rate_per_order
  }
  SKU {
    uuid id PK
    uuid client_id FK
    text sku_code
    text description
  }
  MOVEMENT {
    uuid id PK
    uuid sku_id FK
    text type
    int quantity
    timestamp occurred_at
  }
  INVOICE {
    uuid id PK
    uuid client_id FK
    date period_start
    date period_end
    text status
  }
  INVOICE_LINE {
    uuid id PK
    uuid invoice_id FK
    uuid rate_card_id FK
    text description
    numeric amount
    numeric sst_amount
  }
    

Key constraints

• movement.sku_id must resolve to a SKU whose client_id matches the movement's own recorded client — enforced in application logic plus a database check, since this is the exact invariant that must never silently break.
• invoice.status is an enum: draft → reviewed → sent → paid; a sent invoice's lines become immutable — corrections happen via a new adjustment line, never an edit in place.
• Unique constraint on (client_id, sku_code) — SKU codes only need to be unique within one client's catalog, not globally.

Core API endpoints

Two distinct contexts: the warehouse floor (phone, thumbs, gloves, moving) and the back office (desktop, billing, setup). Design for both, don't force one UI to serve both badly.

Sitemap

Empty & error states worth designing deliberately

• No clients yet: dashboard shows one clear "Add your first client" action, not a blank chart.
• Scan fails to read a barcode: manual SKU search/entry fallback right on the scan screen — a warehouse floor with poor lighting or a damaged label is normal, not an edge case.
• Out-scan exceeds on-hand quantity: block with a specific message ("Only 4 units of SKU-1092 on hand for Client A") rather than a generic error — this is the exact moment a billing dispute would otherwise start.
• Draft invoice has zero activity for the period: show it plainly rather than silently skipping the client, so the owner notices and investigates rather than missing a bill entirely.

Responsive requirements

The scan screen is mobile-first and should work one-handed in portrait orientation. The back-office screens are desktop-first but must degrade to usable (not broken) on a tablet, since an owner will likely check things from a phone between warehouse visits.

Sized for one developer, sequenced to get a pilot warehouse live as early as possible rather than building the full spec before anyone uses it.

Commercial assumptions that must be validated before full development starts

• Total addressable count: how many warehouses in Malaysia actually operate at this specific 1–15 client scale (too small to need enterprise WMS, too multi-client for a single-tenant inventory app)? This blueprint assumes the segment is real but it has not been sized with real outreach — confirm with 5–10 conversations before building past Phase 2.
• Willingness to switch from spreadsheets: an operator who has run this manually for years may resist changing a working-enough process — validate that the billing-accuracy pain is costing them real money (a specific dispute, a specific undercharge) before assuming urgency.
• SST applicability and rate: confirm with an accountant that storage/handling services for this operator type are taxed the way this blueprint assumes — getting this wrong on a client-facing invoice is a trust-breaking mistake, not a cosmetic one.
• Spreadsheet import compatibility: every pilot's existing spreadsheet will look different; the real onboarding effort scales with how messy that data is, not with the product's own complexity.