When Should an Internal Tool Become a SaaS Product?
A practical decision framework for turning useful internal software into a repeatable SaaS product.
Start with a repeated problem, not an impressive tool
An internal application can be valuable because it fits one team's process perfectly. That fit is also the central risk in productisation: the same workflow may not exist elsewhere. Before considering a SaaS launch, identify the job the software performs, how often it occurs and how costly it is when handled manually. Interview prospective buyers outside the original company. Ask them to describe their current process before showing the tool.
Look for independent demand
Interest from colleagues is evidence of internal usefulness. Demand from other organisations is stronger evidence of a market. Find out who owns the budget, what alternative they use, what they would pay to change and which requirements differ between companies. A pilot with an external user is more informative than a large backlog of proposed features. Note objections as carefully as positive reactions.
Test whether the product can repeat
A product needs a stable core and deliberate configuration. Map every rule tied to the original company: permissions, terminology, workflows, pricing, documents and integrations. Some differences can become settings; others may reveal different products. A separate deployment and custom code for each new customer usually signals that product boundaries are still unclear.
Count the operating work
The original team may have provided onboarding, support and fixes informally. A commercial product must handle identity, tenant isolation, billing, privacy, support, monitoring and upgrades. Include those costs when estimating margins. A technically reusable tool can still be a poor business if every customer requires substantial manual implementation.
Make a staged decision
Keep it internal if the pain is unique. Validate externally if the market is plausible but unproven. Commission a blueprint when there is a defined buyer, a repeated problem and enough evidence to investigate architecture and pricing. Productise only when the expected return can justify the build and ongoing operation. VELA's Opportunity Check offers a first indication; it does not replace customer research or technical due diligence.