Practice
Multi-tenant SaaS and custom software development
NextWR builds business platforms that several organisations use at once, each seeing only its own data. The tenant boundary, the permission model and the API are designed before the first screen.
A multi-tenant platform is one deployment serving many organisations. Every school, business or branch that signs up gets its own users, its own records and its own configuration, and none of them can reach another's data. That sounds like a filter on a query. In practice it is a decision that touches the data model, every endpoint, the background jobs and the reporting.
NextWR puts the tenant into the access path rather than treating it as a column added later. Records carry the organisation they belong to, and every query starts from the caller's organisation and works down. A query that cannot name its tenant does not run. Onboarding a new organisation is then a row in a table, not a new deployment to patch and migrate.
Permissions sit at the API boundary, never only in the interface. A hidden button is not a permission: it is a hint rendered by code running on a machine we do not control. Each request is checked against the caller's organisation and role before it reaches data, and the interface reflects that state rather than deciding it. The rules then become testable without a browser.
Around that core sit the parts a platform needs to be usable: an admin dashboard for the people who run it, a settings model so each organisation can differ without a code change, exports, and an API that web and mobile clients share so a rule changes in one place.
What is included
- Data model with the tenant in the access path, and migrations
- Role-based access enforced at the API, with the negative cases tested first
- Admin dashboard for the people who operate the platform
- One REST API shared by the web and mobile clients
- Per-organisation configuration, so tenants differ without a code change
- Deployment, backups and monitoring on infrastructure the client owns
Not included
- Brand identity, logo design and marketing copy
- Paid advertising and content production
- Accounting, payroll or tax logic, which we are not qualified to own
Common questions
Can you take over a platform that is already live?
Yes, starting with a written read of what exists: where the tenant boundary is actually enforced, what the tests cover, and what would break first. That read is billable work and it stays with the client whether or not we continue.
Why multi-tenant rather than one instance per client?
Separate instances look simpler on day one and become unmanageable by the tenth client: ten databases to migrate, ten deployments to patch, ten places for a bug to hide. Tenancy in the data model costs a week at the start and saves the rewrite later.
Projects that use this
Multi-tenant SaaS
School management platform
A multi-tenant platform for schools and businesses: classes, class groups, students, parents, teachers and subjects, with every operation scoped to one organisation.
POS and QR menu
Restaurant platform
Restaurant management with a point of sale, a digital menu reachable by QR code, orders, memberships, multi-store support and multi-currency wallets.
Architecture
Enforcing multi-tenant permissions at the API layer
Tenant isolation is easy to describe and easy to get wrong in a way that stays invisible until a customer sees a row belonging to someone else.
Tell us what you are building.
Write in English, French, Romanian or Arabic. Every message gets a written answer within one business day.