Turning Internal Software into a SaaS Product: What Has to Change

Turning internal software into a SaaS product means removing the assumption that one organisation, one set of trusted users and one support team are always present. Before the first outside customer signs up, the system needs tenant isolation, self-service onboarding and offboarding, a plan and entitlement model, customer-facing identity, documented operations and honest answers to security questionnaires. The features themselves usually change the least.

This guide is for companies that built a system for their own use, such as a dispatch tool, a scheduling system or an ordering platform, and now have other businesses asking to use it. It covers what has to change, in what order, and when productising is the wrong move.

What changes when internal software becomes a product?

Almost everything around the features changes: who the users are, where settings live, how data is separated, how people are billed and how problems are handled. The table below compares the two worlds.

Which single-tenant assumptions have to be removed first?

Start with three: hard-coded configuration, data without a tenant key, and administrative backdoors. Each one can leak one customer's data to another or block a second customer from working at all.

• Hard-coded company details. Your name, logo, currency, tax rates, time zone, fiscal year, email sender address and document numbering. Each becomes a tenant setting. Invoice and order numbers need their own sequence per tenant.
• Data without a tenant key. Every table, file storage path, cache key, search index, background job, report and export must carry a tenant identifier. Unique rules change too: a customer code that was unique across the database becomes unique within a tenant.
• Administrative backdoors. Shared superuser passwords, "log in as anyone" without an audit trail and direct database edits. Replace them with support access that is logged, time-limited and visible to the customer's own administrator.
• Global scheduled jobs. A month-end job that runs at midnight assumes one time zone and one calendar. Jobs have to run per tenant.
• Integrations wired to your own systems. Your ERP, your mail server, your payment account. They become per-tenant connectors with their own stored credentials, or they are removed from the product.
• Your own business policies. Approval limits and workflow rules that reflect how your company works. They become configuration, or they stay out of the product.

A practical test: create a second tenant in a staging environment with deliberately different settings (another currency, time zone and language), then run every workflow as that tenant. Anything that breaks, shows the first tenant's data or uses the first tenant's settings is a single-tenant assumption still in the code.

Which tenancy model should you choose?

Choose based on the isolation your customers will require, the number of tenants you expect and how much operational work you can carry. Many B2B products start with a shared database and an enforced tenant key, and offer separate databases to customers who need them. Our guide to multi-tenant SaaS architecture compares the models in detail, so this guide does not repeat it.

The point specific to retrofitting is enforcement. In an existing internal system, tenant filtering usually has to be added to hundreds of queries. Relying on every developer to remember a filter will eventually fail. Enforce it in one place instead: a data-access layer that refuses unscoped queries, database-level policies such as PostgreSQL row security policies, or both. Then write automated tests that try to read another tenant's records and expect a refusal. The OWASP Top 10:2025 lists Broken Access Control first (A01:2025), and in a multi-tenant product a tenant leak is exactly that failure.

How do tenant onboarding and offboarding work?

Onboarding takes a new customer from sign-up to doing real work without developer help. Offboarding returns their data and removes it on a schedule you have stated in advance.

A typical onboarding flow:

1. Account creation, either self-service or by your sales team
2. Tenant provisioning: default settings, roles and optional sample data
3. Invitation of the first customer administrator
4. Import of master data through validated templates, with clear error reports
5. Integration setup, such as accounting or email connections
6. A go-live checklist the customer can see

Offboarding needs decisions before the first contract, because customers will ask:

• Export. What the customer can download, in which formats (for example CSV or JSON plus attached files), and whether export is self-service.
• Suspension versus deletion. What happens when a subscription lapses, and how long data is kept in a suspended state.
• Deletion schedule. When data is deleted from the live system, and when backups containing it age out.
• Confirmation. A written confirmation once deletion is complete.

What identity and access features do business customers expect?

Start with secure email sign-in with multi-factor authentication, roles defined per tenant and invitation flows. Add single sign-on and automated user provisioning later, as a business tier, once larger customers ask for it.

• Users and tenants are separate. One person may belong to several tenants, for example an accountant serving several clients. Design for that from the start.
• Tenant administrator role. Customers manage their own users and roles. Your support team should not be doing it for them.
• Single sign-on. Business customers will ask for SAML 2.0 or OpenID Connect so their staff sign in through the company identity provider.
• Provisioning. Larger customers often want accounts created and disabled automatically. SCIM 2.0, defined in IETF RFC 7644, is the standard protocol for this.
• Audit log. Sign-ins, role changes and exports, visible to the customer's administrator.

Many products put SSO in a higher tier because larger customers ask for it and each connection adds setup and support work.

How should billing, plans and entitlements be designed?

Keep three things separate: the billing provider that charges customers, the plan catalogue that describes what you sell, and entitlements that your code checks. Code should ask "is this tenant entitled to advanced reporting?", never "is this tenant on the Business plan?".

Billing providers increasingly support this split. Stripe's Entitlements documentation, for example, describes attaching features to products and sending a webhook when a customer's active entitlements change, so the application grants or revokes access. Another option is a merchant of record: Paddle describes itself as one, meaning it resells your product and takes responsibility for collecting and remitting sales tax and VAT. A merchant of record simplifies tax handling; a payment processor gives you more control but leaves tax registration and filing with you. Decide with your accountants.

Settle these rules before launch:

• What happens when a payment fails: a grace period, then read-only access. Never delete data on the first failed payment.
• What happens on downgrade when a tenant is over the new plan's limits.
• How trials end, and what data a trial keeps.
• Who can change the plan: the customer administrator only, or your sales team too.

Where is the line between configuration and customisation?

Configuration is anything a tenant changes through settings while running the same code as every other tenant. Customisation is code written for one customer. A SaaS product survives on configuration; per-customer code branches are how a product slides back into being a services business.

Decision rules that hold up:

• If several customers need it and it fits the product direction, build it as a configurable feature for everyone.
• If one customer needs it, offer the API and webhooks, or deliver it as a separately agreed service outside the core product.
• Never fork the codebase per customer. Use per-tenant feature flags, and retire them once a feature is generally available.
• Custom fields, configurable approval steps, document templates, roles and webhooks answer most "can you change this for us" requests.

What support and operations does a SaaS product need?

Paying customers expect to know when the system is down, how fast you will respond and that you can restore their data. Most internal tools have none of this written down.

• Monitoring and alerting, with a named person on call
• A status page hosted separately from the product, so it stays up when the product does not
• An incident process: severity levels, customer communication templates and a review after each incident
• A support channel and ticketing system, with response targets you can actually meet
• Backups that are tested by restoring them, on a schedule
• Per-tenant restore: the ability to recover one tenant's data without rolling back everyone else. In a shared database this usually means restoring a copy to a separate environment and extracting that tenant's records, so rehearse it.
• A release process with staging, backward-compatible database migrations and release notes
• Infrastructure cost tracked per tenant, so pricing reflects what customers actually cost to serve

Our security and data protection page sets out how we approach access control, backups and data handling in the systems we build.

What will customers ask in a security review?

Expect a security questionnaire before any mid-sized customer signs. Some send a standard set, such as the Cloud Security Alliance's CAIQ, which is built around its Cloud Controls Matrix; many send their own spreadsheet. The topics repeat:

• Hosting provider and data location
• Encryption in transit and at rest
• Staff access to customer data, MFA and access reviews
• Tenant isolation and how it is tested
• Backups, recovery objectives and restore testing
• Incident response and how customers are notified
• Vulnerability management and penetration testing
• Subprocessors and where they operate
• Secure development practices and code review
• Logging, retention and data deletion

Prepare a standard answer pack and keep it truthful. Do not claim certifications you do not hold; audits such as SOC 2 or ISO 27001 are separate projects with their own timelines. OWASP's Application Security Verification Standard (ASVS 5.0) is a useful structure for the application-level answers, because it turns "is it secure?" into specific requirements you can test.

Which legal and commercial items should you settle with advisers?

These items need lawyers and accountants, and this guide is not legal advice. List them early so they do not block the first sale:

• Subscription terms. Service description, payment terms, renewal, termination and liability limits.
• Data processing agreement. Under the EU and UK GDPR (Article 28), a customer acting as controller must have a contract in place with you as their processor when you handle personal data for them.
• Privacy policy and subprocessor list. Which third parties process customer data, and where.
• Service levels. Availability commitments and what happens if you miss them.
• Ownership of the code. If an outside firm built the original tool, confirm your contract gives you ownership of the source code and the right to sell it. Our intellectual property and ownership page explains how we handle this: project source code transfers to the client on full payment.
• Tax. Sales tax or VAT on digital services in the countries where customers are located.
• Corporate structure. Whether the product should sit in a separate legal entity.

Readiness checklist

1. A second test tenant runs every workflow without leaks or broken settings
2. Tenant scoping is enforced centrally and covered by automated tests
3. No shared superuser accounts; support access is logged and time-limited
4. Company-specific settings are tenant configuration, not code
5. Onboarding works without a developer, including data import
6. Data export and deletion are defined, documented and tested
7. Roles, tenant administrators and an audit log are in place
8. Plans, entitlements and failed-payment rules are defined
9. Monitoring, on-call, status page and incident process exist
10. Backups are restore-tested, including a single-tenant restore
11. A security answer pack exists and is accurate
12. Terms, data processing agreement and privacy policy are reviewed by advisers
13. Ownership of the code is confirmed in writing
14. Support targets are set at a level you can staff

What does a phased plan look like?

Move in phases with a clear test at the end of each, rather than switching everything on at once.

Writing down the gaps as a requirements document helps at Phase 0; our software requirements brief template gives a structure.

When is turning internal software into SaaS the wrong move?

Productising is a change of business, not just of software. It is often the wrong call when:

• The value is in your know-how, not the code. Other companies may want your process more than your tool. Consulting or a licensed method can earn more with less risk.
• Only one or two companies are interested. A hosted single-tenant copy per customer, run under a service agreement, avoids the multi-tenant rework. It costs more to operate per customer but far less to build.
• The code is deeply tied to your internal systems. If every feature depends on your own ERP and data, a rebuild of the core may be cheaper than untangling it.
• You cannot fund ongoing operations. Support, security reviews, on-call and releases continue whether or not a customer is paying that month.
• Your competitors would be your customers. Selling the tool may give away the advantage it was built to create.

How Timeline Digital helps

We help companies turn internal systems into products, and build new SaaS platforms from scratch. Our SaaS development company page explains how we work on SaaS engagements, and our SaaS product development and SaaS platform development services cover the build itself, from tenant isolation to billing and onboarding. We start with a free pilot of 2 to 3 key modules before the full project, so you can judge working software, such as the tenant layer and onboarding flow, before committing.