FLOW LGX · PART 7 · APRIL 2026

Flow LGX, part 7: the turn — from one company’s tool to a SaaS product

In April 2026, six months after the first brief, the client came back with a bigger idea. The platform worked for their business; other logistics companies had the same problems. Could Flow LGX become a product that many companies use, each managing its own people, with only the platform owner and distributors running the system as a whole?

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

The client decided to turn their internal tool into a product other logistics companies can subscribe to. Because the foundations were solid, we extended the platform instead of starting again.

What the client asked for

The new direction was clear. Flow LGX would no longer be one company’s internal tool. It would be a product: logistics businesses subscribe, invite their own team, manage their own drivers and vehicles, and work with carriers and customers through the platform. Day-to-day control moves to the people using it. Only two levels manage the system as a whole: the super admin, who owns the platform, and distributors, who act as sub-admins over their own part of it.

What had to change

Turning a tool into a product touches almost everything except the core job lifecycle:

  • Who sets up users: instead of an admin creating every account, companies invite their own people as paid seats.
  • Who is a user: carriers, vendors, direct customers and drivers became people who sign in, not names in a list.
  • How carriers join: a public sign-up with vetting and compliance documents replaced phone calls.
  • How money works: subscription plans, per-seat pricing and card payments joined job invoices.
  • How access works: a few fixed roles became nine roles, with fine-grained permissions inside the super admin team.

What we kept

The decision we were most grateful for in April was made back in October: the job lifecycle was written down and the code was organised around it. Jobs, warehouses, inbound and outbound work, scanning, inventory and exceptions did not need to be rebuilt. The shared component library, the single layout, the role list in one file and the per-role API modules all carried over.

So the change was large, but it was an extension, not a rewrite. The problem-solved post on this move explains how we planned it.

Re-planning the milestones

We re-planned the remaining work as a new set of milestones, each ending in something the client could click: access and permissions for SaaS (May), self-service onboarding (June), the marketplace and quotes (July), subscriptions and billing (August), notifications, audit and testing (September), and deployment (October).

What we shipped

  • A written scope for the SaaS version, agreed with the client
  • A list of what changes and what stays from Phase 1
  • New milestones from May to October 2026

Lesson learned

Products change direction. A codebase organised around the core business record survives the change; one organised around the first set of screens does not.