Multi-tenant SaaS with signup, plans, billing and an operator console

Yes, a large part usually carries forward. The screens, business rules and reports that users already trust are normally kept. The foundation underneath needs rework. Every record and file gets an account boundary, anything assuming a single company is replaced, and conditions written for individual clients are removed. Plans, signup and billing are then added. Where the code is very old or has no clear data model, rebuilding parts can be more practical than adapting them. The productisation review sorts each part into these groups before any build is committed.

Multi-tenancy means one running system serves many customers, with each customer’s data kept apart inside it. Separate copies work only while there are two or three customers and someone to maintain them. The cost appears later. Every fix is repeated per copy, the copies drift apart, and each new customer needs a server set up, so running cost grows in step with customer count. Tenancy is the usual choice for many customers on subscription pricing, while a handful of large accounts on negotiated contracts can justify separate instances.

It covers the product layer around the application. Tenancy and isolation, self-service signup with workspace provisioning, and plan and feature limit management come first, followed by trials, upgrades, downgrades, recurring billing, invoices and dunning. Customer onboarding with data import, per-account branding, custom domains, an operator console and audited support access are also included. So are usage reporting, per-account export and deletion, and migration of customers on separate copies. Design, testing, deployment, documentation and training are part of the delivery.

It depends on scope. No fixed price list applies. The main factors are the state of the existing system and how much of it can be reused, plus the isolation model that data volumes require. Pricing complexity matters too. A single flat plan is far less work than metered usage with proration and offers. Further factors are how much onboarding must be self-service and whether customers need their own branding and domains. The depth of the operator console counts. So does the number of installations to migrate. Scoping ends in an itemised proposal, set against the signed tenancy and plan document.

It depends on how much has to change underneath and how quickly the client side decides. The main questions are whether the tenant boundary fits the existing data model or the model needs reworking, and which pricing rules are wanted at launch. Gateway approvals and mandate activation sit with the payment provider, and GullySystem cannot hurry them. The number and condition of installations to migrate count, as does the speed of plan and pricing answers. Launching with one plan and a simple trial, then adding tiers and offers once customers are on board, lets selling start earlier. A schedule is confirmed after scoping.

Recurring collection is set up through the client’s own payment gateway account, using subscription plans, card mandates or bank auto-debit. Charges run on the due date without a manual request. For each charge the product generates a subscription invoice in the format the accountant specifies. It keeps receipts and payment history against the account and can post entries to QuickBooks, Xero or Zoho Books. Tax treatment, invoice numbering series and place-of-supply rules are set by the client’s accountant, and the product is configured to match. Failed charges follow the retry and reminder schedule first. Access is restricted only afterwards.

Isolation is enforced where data is read. Screens are not trusted to do it. Every record, uploaded file, report, export, background job and API call is scoped to its account, so a query without an account context returns nothing. Roles add a second layer inside each account. Before launch, testers log in as one account and go after another’s records through the interface, direct URLs, exports and the API, and anything that responds is fixed. Support staff reach a customer account only through time-limited impersonation, logged against the staff member.

Yes. Logo, colours, invoice and report templates, email sender name and notification content can all be set per account. Where a customer wants the product under its own name, its domain is mapped to its workspace and the SSL certificate is issued and renewed automatically. This white-label setup suits dealers, franchisees and partner firms. Branding on every plan, or only on higher tiers, is a pricing decision made in the console.

The product follows rules the client sets. A failed charge is retried on a schedule and the account owner receives reminders. After a grace period the client defines, the account moves to read-only and then to suspended, and reactivation follows once payment succeeds. Nothing is deleted at that point. A customer who chooses to leave can export its own data as Excel or CSV files. The account is then archived and removed on the retention schedule published to customers.

The client does. On handover the client receives the full source code repository, database design, deployment runbook and intellectual property ownership. Hosting, payment gateway, domain and communication accounts are created in the client’s own name from the beginning, so subscription revenue reaches the client’s bank account directly. Customer data sits in infrastructure the client controls. There is no licence fee to GullySystem. There is no revenue share either. Continuing with another team stays easy.

Yes, in two directions. Outward, the platform connects to the client’s payment gateway, accounting software, WhatsApp Business, email and SMS providers, and analytics. Inward, a documented API and webhooks are built for customers, who can push masters in, pull transactions out or let their own vendor build against the product. Keys are scoped to one account and gated by the plan. Where customers commonly run QuickBooks or a particular billing package, that connector can become a paid feature of a higher tier.

Yes. The people who run the product are trained on the screens they use: the person handling accounts and renewals, the person answering support and whoever approves offers and refunds. A written operations manual accompanies the training. After go-live, a warranty period covers defects, and an optional support agreement covers monitoring, gateway and app-store changes, releases and new features as account numbers grow. The project needs a decision-maker who settles plan and pricing questions quickly. It also needs access to the existing system and to any customer installations being migrated. A payment gateway account activated in the client’s name is required, along with a couple of real customers willing to be the first accounts. Pricing decisions are a common cause of delay.

It depends on how close the offering is to standard. A no-code builder or a white-label product is worth trying while the offering is standard and demand is untested, because the start is quicker and abandoning it costs little. It becomes the wrong foundation once pricing, workflow or reporting is the reason customers choose the product. A white-label product limits the client to what its owner built, and a no-code builder struggles once the data model or billing rules get specific. Ownership matters too if the client plans to sell the underlying intellectual property or raise investment on it. A white-label arrangement usually means the client does not own the product. Where a faster, cheaper option reaches the same answer, that option is the one recommended, because spending more would add nothing.