// SaaS Development
SaaS platform development where tenancy, subscriptions and entitlements are part of the architecture rather than a later retrofit. Onboarding a customer should be a configuration change, not a deployment.
Most SaaS products start as a system built for one customer. It works, a second customer wants it, and tenancy gets bolted on around a schema that assumed there would only ever be one. Everything after that is expensive.
We treat tenants, subscriptions, tiers and per-feature entitlements as how the platform is shaped, not as a feature. Data isolation, role models and billing all follow from that one decision, and it is very hard to change later.
The test of a real SaaS platform is what happens when you sign a customer. If it needs a deployment, you have a series of installations. If it is a configuration change, you have a product.
The parts that are painful to add later, and are therefore designed in from the first milestone.
Tenant boundaries enforced at the data layer, so one customer’s data cannot surface in another’s reports. The decision everything else depends on.
Data isolation · Tenant configuration · Per-tenant branding
Plans, tiers, trials, upgrades, downgrades and the proration nobody thinks about until the first mid-cycle change.
Plans & tiers · Trials · Proration · Payment provider integration
What each tier can actually do, enforced in one place rather than scattered through the code as conditionals.
Per-feature flags · Usage limits · Tier gating
Permission models that hold up when a customer has an owner, managers, staff and a read-only accountant.
Role models · Granular permissions · Per-tenant admin
Where the work happens off the browser, a desktop client against the same backend, including hardware the browser cannot reach.
One backend · Shared auth · Offline & sync · Hardware access
Customer-facing reporting inside a tenant, and operator reporting across all of them, without one leaking into the other.
Tenant reporting · Operator dashboards · Scoped exports
// Common Questions
Every customer runs on one shared platform, with their data isolated from everyone else’s. The alternative, a separate deployment per customer, looks simpler at two customers and becomes unmanageable at twenty.
Sometimes, and it is worth being honest that it is usually a significant rebuild of the data layer rather than a feature. We will look at what you have and tell you whether retrofitting or rebuilding the core is the cheaper path.
Yes. Plans, tiers, trials, upgrades and downgrades, integrated with your payment provider, including the proration and failed-payment handling that gets discovered late otherwise.
Through a desktop client, yes. We have built platforms where the web application runs the business and a cloud-synced desktop client reads industrial hardware over a serial connection, against the same backend.
National Weighs, a multi-tenant weighbridge platform: subscriptions, tiers and per-feature entitlements, a web platform for head office, and a desktop client in the cabin reading the weighing indicator. There is a full case study on this site.