FLOW LGX · PROBLEM SOLVED · MAY 2026

Problem solved: turning a single-company app into SaaS without a rewrite

When a client changes direction halfway through, the expensive answer is “we need to start again”. On Flow LGX we did not. This is how a single-company logistics platform became a multi-company SaaS product while the original features kept working.

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

How we changed direction mid-project without a rewrite: sort every module into keep, extend or new; change access first; then add the new areas beside the old ones.

The problem

Six months of work assumed one company. Users were created by an admin. Carriers were records, not people who sign in. There were no plans, seats or subscriptions. The client now wanted all of that — and did not want the working warehouse and job features to break while it was added.

Step 1: sort everything into keep, extend and new

We listed every module and put it into one of three groups:

  • Keep — jobs, warehouses, inbound and outbound, scanning, inventory, exceptions and the shared UI. These describe logistics work, not who owns the account, so they stayed as they were.
  • Extend — the role list, menus, route protection and dashboards. These needed new roles and permission checks, but their structure was already right.
  • New — carrier onboarding and compliance, vendor and direct-customer areas, the quote marketplace, subscriptions, seats and card payments.

Step 2: change access first

Everything new depended on knowing who a user is and what they may do, so roles and permissions came first (part 8). Because roles lived in one file and every area already sat behind a protected route, new roles were additions rather than edits scattered across the code.

Step 3: add new areas beside the old ones

New roles got new page folders and new API modules — vendor, direct customer, distributor — beside the existing ones. Shared features such as inventory and scan matching were reused by the new roles instead of copied. Existing pages kept working because nothing they relied on was renamed or removed.

Result

The SaaS version shipped on top of the original platform. The warehouse floor kept scanning through the whole change, and the client never had to pay twice for features that already worked.

Lesson learned

Before estimating a change in direction, sort every module into keep, extend and new. The “keep” column is usually longer than anyone expects.