How we built a white-label SaaS platform

The project brought contact management, inventory and field-team administration into one platform. It also needed to run under different business brands without maintaining a separate codebase for each one.

Offline work was a central requirement. Field agents needed to read saved information and record changes when a connection was unavailable.

Separate shared features from tenant settings

The shared application handled contacts, products, teams, communication and administration. Each business could configure its branding and enabled modules.

White-labeling involves more than changing a logo. Tenant data must remain separated, roles must be enforced on the server, and exports, logs and background jobs must respect the same boundaries.

Plan for interrupted connections

The application used cached assets and saved data to support offline work. Submissions could wait on the device until a connection returned.

Static assets: use a versioned cache
Saved records: display an available local copy when offline
Pending changes: retain locally and retry when connected

The interface needs to make the distinction between a local save and a confirmed server update clear. A failed retry must not quietly discard work or create a second transaction.

Resolve conflicting edits deliberately

The project used a last-write-wins approach with an audit trail for review. That is a tradeoff: a later change may overwrite an earlier one. It is not suitable for every kind of data.

Stock movements and financial records deserve particular care. A new implementation should decide whether to merge, reject or request review of conflicting changes rather than applying one rule to every field.

Test permissions and device behaviour

Camera-based QR scanning required permission handling, camera selection and a fallback when scanning was unavailable. Tests needed to include the phones used in the field, not only a desktop browser.

Roles controlled access to modules and records. Administration included an activity history and communication settings. Messaging workflows also needed delivery-state handling and controls appropriate to the provider’s requirements.

Lessons for another project

Define the offline data model early. Test account switching, sign-out, interrupted synchronisation and recovery after an update. Agree which actions may happen offline and which need a server connection.

Shared branding configuration can reduce duplicated work, but operating several tenants adds testing and support responsibilities. The decision should follow the business model and the team’s capacity to maintain it.

Our PWA guide explains the broader options. Contact us if you need to assess a platform with similar requirements.