Turning your internal tool into a SaaS product

Turning an internal tool into a SaaS product means moving from software that serves one company to a subscription product sold to many. The domain logic often survives. Almost everything around it changes: each customer's data must be isolated, pricing and billing must exist, support has to be organised, contracts have to be signed, and you must prove you own the code. In short, you become a software vendor.

The story is familiar. A company builds, or has someone build, a tool that solves a real problem in its industry. A supplier, a partner or even a competitor sees it and asks whether it is for sale. That question deserves a careful answer, because the distance between a useful internal tool and a sellable product is larger than it looks from the inside.

Internal tool versus product: what actually changes

An internal tool has one customer, who is also its owner. It can live with hard-coded settings, a manual backup routine and a screen only the finance team understands. A product sold to strangers cannot.

The last row is the one teams underestimate. As long as the tool is internal, every request from the team can be honoured. Once it is sold, a feature requested by one customer has to make sense for the others, or the product slowly becomes a collection of one-off versions nobody can maintain.

Five workstreams to become a software vendor

1. Make the tool multi-tenant

This is the main technical job. Each customer company must see its own data and nothing else, with its own users, roles and settings. A tool designed for a single organisation usually stores everything in shared tables, so the notion of "customer" has to be introduced everywhere, from the database to exports and reports.

The problem resembles a network of branches where each site only sees its own scope, which our article on multi-site back-office software covers. A SaaS goes further, because tenants are separate legal entities. The architectural options are compared in multi-tenant SaaS architecture explained.

On top of that come self-service or assisted sign-up, user invitations, password resets and account deletion with its data: features an internal tool never needed.

2. Set a price and bill for it

Internal software is free to its users. A product needs a pricing model customers understand: per seat, per location, per volume or by feature tier. A good model follows the value customers get, not your cost structure. The options are discussed in how to price a SaaS product.

Technically, recurring billing means subscriptions, trials, mid-cycle plan changes, failed card payments, dunning and compliant invoices in every country you sell to. A payment provider handles a large part of it, but the integration still has to be built and tested.

3. Run support and operations

A paying customer expects the service to be up, questions to be answered and bugs to be fixed. That means documentation, a clear support channel, monitoring that alerts you before customers do, tested backups, regular security updates and an incident procedure.

This is often what decides whether the project is viable. A company whose core business is not software has to choose between hiring a team or handing operations to an external team that stays on the product for the long run.

4. Put contracts in place

If you host personal data on behalf of customers in the European Union, the GDPR generally treats you as their processor. Article 28 of the regulation requires a binding contract that describes the processing, and it governs your own subcontractors, such as your hosting provider: you need your customers' prior written authorisation, and those subcontractors must be bound by the same data protection obligations. Customers outside the EU will have their own requirements, often similar in spirit.

Then come terms of service, an availability and response-time commitment you can actually keep, and an exit plan explaining how a customer gets its data back if it leaves. These documents carry real liability, so have them reviewed by a specialised lawyer before the first sale.

5. Confirm that you own what you sell

You can only sell what belongs to you. In many jurisdictions, software written by employees as part of their job belongs to the employer by default, but the rules vary and employment contracts can change them. If a contractor or agency built the tool, everything depends on their contract: a licence to use the software internally does not let you resell it to third parties. Rights are defined case by case in the contract, and it is the first document to reread.

Check the components too: open source libraries whose licences attach conditions to redistribution, paid modules bought for internal use, and third-party services whose terms forbid resale.

Validate demand before you industrialise

A partner's interest during a demo is a signal, not proof. A few questions help avoid building a product nobody buys:

• Is the problem shared across the industry, or specific to how your company works? A tool shaped around one organisation sells poorly.
• Who would pay, and from which budget? The owner, an operations manager, a group IT department: each decision path changes the sales cycle.
• How many target companies exist, and how do you reach them? Trade shows, industry associations, a reseller network?
• What do they use today? If the answer is a spreadsheet, the case made in replacing Excel with a custom application is your best sales argument. If it is a competing product, you need a real difference.

The safest method is still to show before you build: a demo version, or a prototype of the multi-customer version, presented to companies that owe you nothing, with a request for a concrete commitment at the end.

What you keep and what you rework

A tool that has run for years carries value that is easy to overlook: business rules tested against reality and screens validated by real users. That knowledge survives even when the code has to change.

What usually gets reworked:

• the data model, to introduce tenant separation;
• authentication and permissions, designed for a single organisation;
• hard-coded settings, which become per-customer configuration;
• hosting, which must carry several customers and meet their requirements, including where data is stored;
• accumulated technical debt, tolerable internally but costly once external customers feel its effects.

A code audit settles the choice between evolving and rebuilding, and prices each option. The cost items of a SaaS are broken down in the cost to build a SaaS platform.

What a live SaaS demands: an example

Izi-Devis, the quoting and invoicing software for French tradespeople that LPR Studio designs, builds and runs itself, did not start as an internal tool: it was designed as a product from day one. It does show what a SaaS requires once it is live:

• an entry offer and a subscription, with a limited free plan and a paid plan whose price is published;
• a living product, with new releases every week since launch, driven by user feedback;
• continuous operations: hosting in Europe, monitoring, backups and updates;
• bridges to existing tools, such as accounting exports and imports from other quoting software, because no customer starts from scratch.

None of these would have been needed for a tool used by a single company. That is the gap to plan for.

The roadmap, step by step

1. Check ownership of the code and its components, contractor agreement in hand.
2. Test demand with outside companies, using a demo and a request for commitment.
3. Audit the existing code to decide between evolution and rebuild.
4. Prototype the multi-customer version before building it: sign-up, customer workspace, settings, billing.
5. Prepare the contracts: terms of service, data processing agreement, service levels, exit terms.
6. Set up operations and support before the first paying customer, not after.
7. Open gradually, with a few pilot customers, then widen.

At LPR Studio, a prototype of the multi-customer version is free and presented on a video call within 5 business days. It lets you see the product before industrialising it, and show it to future customers. Three engagement models can then build it: fixed price, a subscription with no upfront development cost, or SaaS publishing.