SaaS product development, planned as the workflow a tenant lives through
SaaS product development is the work of building one application that many customer organisations use at once, each with its own data, users, settings and subscription state. The feature list matters less than the tenant's path: sign-up, configuration, daily use, plan changes, releases and exit. Plan that path first and the build order follows.
Submit a project See the related serviceReviewed by David Nguyen (CEO) · Updated 28 Sep 2026
OutsourcingVN is operated by Netbase JSC, which sells this work. Since 2020 Netbase has worked as offshore development and managing partner on a multi-tenant cloud ERP SaaS for a US client that is not named, and that record is the evidence behind this page. What it does and does not show is set out under proof.
Who is in this workflow
-
The tenant administrator
Signs the organisation up, invites colleagues, sets roles and changes the plan.
-
The tenant's users
Do the daily work and only notice the platform when it is slow or a permission blocks them.
-
The product owner
Decides what is configuration, what is a feature and what goes into the next release.
-
Support and success staff
Need to see a tenant's setup without seeing its private data.
-
The platform operator
Watches the whole fleet of tenants, patches it and answers for an outage.
-
Integration partners
Build against the public API and break when it changes without warning.
Where does a SaaS build usually go wrong?
-
Tenancy is decided late
A single-customer prototype gains a tenant column later, and every query becomes a possible data leak.
-
Roles are one flag
"Admin or not" survives the first customer and fails the fifth, when an agency wants a client-only view.
-
Plan state lives in the payment tool
The application cannot say whether a tenant is on trial, active, past due or suspended, so access and billing disagree.
-
Customisation becomes forking
A large customer's special field turns into a branch nobody can merge.
-
Releases hit everyone at once
There is no way to hold a change back for one tenant or roll it out gradually.
-
Offboarding was never designed
Nobody can export a tenant's data cleanly or prove it was deleted.
The target flow
-
Provision the tenant
Sign-up creates the organisation, its first administrator, default settings and an isolated data scope in one step.
-
Set roles and boundaries
Roles are defined per tenant, and the platform's own staff get a separate, audited support role.
-
Configure without code
Custom fields and configurable workflows cover the common variations, so a release is not needed for each customer.
-
Track the plan state
Trial, active, past due, suspended and cancelled are states the application owns; the payment provider reports events into them.
-
Integrate through a versioned API
External tools connect through documented, versioned endpoints and webhooks.
-
Release in rings
Changes reach internal tenants first, then a pilot group, then everyone, behind flags that can be switched off.
-
Observe per tenant
Errors, load and usage are visible by tenant, so one noisy customer is found before it slows the rest.
-
Exit cleanly
A tenant can export its data, and deletion follows a recorded schedule.
Where does the system boundary sit?
The product owns tenancy, identity and roles, configuration, plan state, the API and the release mechanism. It usually does not own card processing, tax calculation or accounting; those stay with specialist providers connected by events. If the question is still whether to build at all rather than subscribe to an existing product, start with custom build versus SaaS before scoping this workflow.
Data and integrations
The core objects are the tenant, user, role, membership, plan, subscription event, configuration record, feature flag and audit entry. Three isolation models are common, and the AWS Well-Architected SaaS Lens names them silo (dedicated resources per tenant), pool (shared resources) and bridge (a mix, decided service by service). Choose per module: a regulated or heavy tenant may justify a dedicated database while the rest share one.
On the cloud ERP record, the stack includes React and Next.js, Laravel and Strapi, PostgreSQL, MySQL, MariaDB and MongoDB on AWS. More than one database suits modules with different data shapes, but every added engine is another thing to back up, patch and monitor for every tenant.
What AI does here, and what it does not
The recorded phase-one scope of the cloud ERP contains no AI feature, and none is claimed for it. In a new SaaS product, reasonable AI candidates are support triage, drafting help-centre answers from the product's own documentation, and classifying inbound tenant requests, each with a person approving what reaches a customer. Tenant data used for AI must respect the same isolation as everything else. Netbase works with commercial and open-source AI models chosen per project (model-agnostic); no vendor partnership is implied.
Delivery modules
- Tenant provisioning and organisation settings.
- Identity, per-tenant roles and an audited support role.
- Custom fields and configurable workflows.
- Plan and subscription state with provider webhooks.
- Versioned public API and outbound webhooks.
- Feature flags and ring-based releases.
- Per-tenant logging, metrics and usage reporting.
- Data export and deletion.
These are delivered as Custom Product Engineering milestones. Netbase's delivery lifecycle: discovery and strategic alignment; team assembly and architecture planning; agile execution with outcome-based milestones; modular components; training and rollout; ongoing support. Project teams draw on business analysis, project management, solution architecture, development, QA and UI/UX roles. Most Netbase projects are agreed as fixed-scope contracts after discovery; milestone-based arrangements are also available. Governance of a long-running build follows the project delivery page, and each milestone should close against written acceptance criteria.
Where the pattern holds
-
Vertical business suite for SMEs
- What changes in the plan
- Many modules share tenancy, roles and custom fields
- Recorded example
- The cloud ERP phase one for agency SMEs
-
Platform with a mobile client
- What changes in the plan
- The API is a product in its own right, with device tokens and notifications
- Recorded example
- RB Marketplace customer API
-
Single-customer internal tool
- What changes in the plan
- Tenancy is unnecessary; a normal application is cheaper
- Recorded example
- None needed
-
Enterprise tenant with strict data rules
- What changes in the plan
- Silo storage for that tenant, pooled services elsewhere
- Recorded example
- None recorded
For RB Marketplace, Netbase built a Laravel multi-vendor marketplace whose customer REST API carries device tokens and notifications, which is the shape a SaaS mobile client needs; the marketplace app record shows it. That project is a marketplace rather than a subscription product, so it supports the API row only.
Proof from delivery
The multi-tenant cloud ERP SaaS record is the evidence. Since 2020, Netbase has worked as offshore development and managing partner on that platform for a US client. Phase one, from 2020 to 2023 and aimed at agency SMEs, covers CRM, real-time messaging, HR, a knowledge base, custom fields and workflows, work and project management, and API integrations. The operating context those modules serve is described under ERP and back-office operations.
That is the whole delivery record for this page. The client and product are not named, and no user count, tenant count, uptime or revenue figure is published. The retail phase two was planned work when the profile was written and is not presented as delivered. Netbase has no published record of building a SaaS billing engine or a usage-metering system, so those modules are offered as capability, planned in discovery, not shown as past work. The methodology page explains how records are labelled.
This record covers phase-one scope for agency SMEs; the client and product are not named, and no usage or business result is claimed.
Keep Reading
This record sets out what was delivered on each side, what deliberately stayed in the web panel, and what the project documents do not support.
Keep ReadingCommon questions
If more than one customer organisation will use it within the first year, yes. Retrofitting isolation into a single-tenant data model is one of the most expensive changes a SaaS product can face.
For custom development the client owns the IP created for it; Netbase productized modules and products are licensed, not transferred. The IP ownership guide covers what to put in the contract.
Usually not. A payment provider handles cards and invoices, and the application keeps the plan state and reacts to the provider's events.
Put their variation into configuration or a feature flag, and refuse changes that only make sense for one tenant unless they are paid for as a separate, isolated extension.
The tenant model, the role list, plan states and the first two releases. The SaaS discovery questions set out what to prepare.
Services behind this solution
Custom product engineering for a bounded release outcome
One defined release of your product, built to named outcomes and handed over with acceptance evidence.
Learn More
Scope your SaaS product
Bring your first three target customers, what each would configure differently, and how you expect to charge them. Other workflows are listed under solutions. When you are ready, submit a project naming the tenant you want live first. OutsourcingVN is Netbase's own outsourcing-services platform.