FLOW LGX · PART 9 · JUNE 2026

Flow LGX, part 9: self-service onboarding for carriers and customers

A SaaS platform cannot depend on an admin typing in every carrier. In June 2026 we built the way in: carriers and vendors apply themselves, upload their documents, and are reviewed before they can work on the platform.

About this project

Month by month, how a logistics platform for a Toronto client went from a simple brief to a live, multi-company SaaS product.

In short

Carriers apply online, upload insurance and other documents, and are reviewed before they can work. Which documents are required — and when they expire — are settings, not code.

A public way in for carriers

Anyone running a carrier business can open the public “Become a carrier” page on flowlgx.com and apply. The form is long by nature, so it is split into steps: account and email verification, company details (legal name, trading name and vendor type), contacts, warehouses with their facility type, equipment with quantities, and the regions served — by province or state and ZIP or postal code ranges.

Vendors can also be invited directly. An invite link carries a one-time token that opens their onboarding with the right company already attached.

Compliance documents with rules

Moving other people’s goods requires proof: insurance, registrations, safety certificates. Rather than hard-coding a list, the super admin defines document types — each with a name, a code, an optional template, whether it is required, and whether it expires. Carriers upload against those types, and the platform knows when a document is missing or out of date.

Review before work

Applications arrive in an onboarding submissions area for the super admin team, where a compliance reviewer or onboarding specialist can open the documents, add review notes and approve or reject. Only approved carriers show as compliant in the marketplace.

Terms that know who you are

Different users agree to different terms. The super admin can publish versioned terms and conditions, choose which user types they apply to, and mark them as required. When a new version is published, the right users are asked to accept it.

What we shipped

  • Public multi-step “Become a carrier” onboarding
  • Invite links with one-time tokens for vendors
  • Configurable compliance document types: required, expiring, with templates
  • Onboarding review with notes for the super admin team
  • Versioned terms and conditions per user type

Lesson learned

Make compliance rules data, not code. The list of required documents always changes; a settings page is cheaper than a release.