You have a process clients pay for. Someone has pointed out that the process is the product and you could sell it as software. They are usually right — and the reason it does not happen is that tenancy, onboarding, tiering and billing are roughly a year of engineering before the first customer sees anything worth paying for.
Turn our service into a SaaS product.
Productising a service fails on the unglamorous half. The domain logic — the thing you are actually expert in — is usually the smaller part of the build. The larger part is multi-tenancy, user management inside each tenant, per-tenant configuration, onboarding, trials, plans, feature gating, billing, dunning and what happens when a card fails.
None of that is differentiating. Every SaaS product has it, no customer chooses you because of it, and building it badly is a category of risk that does not show up until you have real customers. Tenant isolation in particular is the kind of thing that either holds absolutely or fails in a way that ends the business.
So the honest calculation for most service businesses is that the productisation is worth doing and the groundwork makes it not worth doing. Changing that calculation means not building the groundwork.
Tenants are a first-class concept in the platform rather than something layered on. Each tenant organisation gets a hard-isolated version of the application, manages its own users, and carries its own configuration — custom fields defined at platform level that control functionality and settings per tenant, optionally editable by the tenant owner.
The subscription engine covers onboarding, free trials, minimum contract periods and tiers that unlock different features across the application. Recurring payments run through Stripe, taken automatically per plan, with the option to pause access when payments stop rather than leaving that as an awkward manual conversation.
What that leaves you building is the part that is actually yours: the process you are expert in, expressed as datastores, forms, workflow and reporting. That is the part where time spent improves the product, and it is where the whole budget should go.
The hardest design question in productising a service is which of your per-client differences are genuine product configuration and which are habits. Configuration becomes instance fields; habits get standardised. Getting this wrong in either direction is the most common way these products become unmaintainable.
Your actual expertise, as datastores, generated forms, workflow and reporting — the same building blocks as any other application, with tenancy already underneath it rather than retrofitted.
Tenant owners create and manage their own users and control their own settings within the bounds you allow. Every hour of customer administration you keep is an hour that scales with your customer count, which is precisely what productising was meant to escape.
Tiers that unlock different features, a free trial to raise sign-up, minimum contract periods where your economics need them, and Stripe taking recurring payments per plan with access pausing on failed payment.
An in-app help library so tenants answer their own questions, a service desk for the ones they cannot, and a status panel so you find out about a performance problem before your customers tell you.
Nothing here is written specially for this use case — it is the same platform every ActiveManage application is built from. The full feature list is on the platform page.
| Feature | What it does | Why it matters here |
|---|---|---|
| Multitenancy | Tenant organisations, each using a hard-isolated version of the application and managing their own users. | The single highest-risk thing you would otherwise be building yourself, and the one where a subtle mistake is existential. |
| Instance configuration | Custom fields available when creating and managing tenants, used to control functionality and settings per tenant — optionally managed by tenant owners. | This is what lets one codebase serve clients who each believe the product was built for them. |
| Subscription engine | Subscriptions with onboarding, integrated billing, free trials and minimum contract periods. | Onboarding and billing are where productisation projects run out of money. Here they are configuration. |
| Tiered feature access | Membership tiers unlocking different features across the application. | Your pricing page becomes enforceable. Without this, tiers are an honour system. |
| Stripe recurring payments | Payments taken automatically per plan, with the option to pause access if payments stop. | Failed payments are handled by the system rather than by an uncomfortable e-mail three weeks later. |
| API engine | Create, read, update and delete endpoints over your data, permission-aware, with token-based clients and call logging. | Your first enterprise customer will ask for an API during procurement. Having one is often the difference between winning and not. |
One tenant, running your process for real, usually with your most patient existing client. Everything about tenancy is easier to verify with two tenants than to design in the abstract.
Self-service onboarding, plans and billing — the parts you only need once you are selling rather than piloting.
You own the product. It runs on the platform, which is updated continuously underneath you, and your team configures the domain layer without needing us in the loop.
Tenancy is a platform-level concept, not application code — each tenant organisation uses an isolated version of the application. That matters because it means isolation is not something each new feature has to re-implement correctly.
Yes, two ways. Instance configuration fields control functionality and settings per tenant, and subscription tiers unlock different features across the application. The first is for bespoke arrangements, the second is for your price list.
The subscription engine handles onboarding, trials and minimum contract periods; Stripe takes recurring payments per plan; and access can pause automatically if payments stop.
Yes, and for most B2B SaaS this comes up in the first enterprise sales conversation. Per-tenant branding is part of instance configuration.
You do. It is built on the platform, which you licence, but the application — the data model, the process, the interface, the customer relationships — is yours, and it is ordinary configuration your own team can change.
Tell us what you are trying to fix and we will tell you whether this is the right shape for it — including when it is not.