Why should an internal custom system not be sold to competitors as SaaS immediately?
Do not assume an internal custom system can be lightly modified and sold to competitors. First use interviews, a manually delivered service, or paid pilots to prove that external customers will buy. Then evaluate multi-tenancy, configuration, billing, security, support, and continuous operations as a separate product. Without paid external validation and a three-year unit-economic model, keep it as an internal efficiency tool.
An internal system serves one company's process, organization, and data. SaaS must serve multiple organizations through a shared product while isolating tenants, supporting configuration differences, upgrading safely, and remaining supportable. Engineering is only part of the change: the company also assumes sales, onboarding, customer success, support, compliance, and long-term service obligations.
When turning a business goal into an executable scope, also compare Should every promotional feature launch in the first product release?; the linked guidance adds context that should be considered in the same decision.
Internal system versus external SaaS
| Dimension | Internal custom system | External SaaS | New responsibility |
|---|---|---|---|
| Users and requirements | One company with fixed workflows | Multiple tenants with conflicting needs and versions | Product choices and configuration model |
| Data and access | One organization's roles and environment | Tenant isolation, tenant administration, import and export | Security, privacy, and audit |
| Charging | Internal investment budget | Plans, subscriptions, trials, renewals, invoices, delinquency | Commercial and billing systems |
| Releases | Scheduled around internal teams | Continuous use and compatibility with existing tenant configuration | Staged release, migration, and version support |
| Service | Internal IT or original team | Support, customer success, SLA, and knowledge content | Continuing operations team |
| Growth | No external acquisition | Sales channels, acquisition cost, activation, and retention | Sustainable unit economics |
Similar pain does not guarantee a market
Competitors may share a problem but use different processes, scales, data conventions, and budgets. Trust is another barrier: will a buyer place operating data in a product controlled by a competitor, and will it believe the roadmap serves customers rather than the seller's core business? A separate entity, credible data isolation, contracts, and product governance can reduce concern but add cost.
Internal satisfaction is not market evidence. Interview a representative set of target buyers to understand their current alternative, budget holder, decision process, and result worth paying for. Then seek a small group of paid design partners using a demo or manual service. The source article's example ranges of 15–30 interviews and 3–5 paid partners illustrate a validation method, not universal success thresholds; the market and buying process determine the appropriate evidence. Free use and compliments do not equal purchase intent.
Three possible routes
| Route | Appropriate when | Investment | Default recommendation |
|---|---|---|---|
| Continue internal use | The system mainly creates the company's own efficiency or advantage | Maintain the current system | Usually the safest; productization is optional |
| Sell consulting, templates, or a managed service | Peers want the method but software needs differ | Content, advisory, and delivery process | Validate payment and common needs first |
| Build an independent SaaS product | Several buyers will pay and core needs are genuinely shared | Continuing product, engineering, sales, support, and compliance | Treat it as a new business |
The technical productization work
Rebuild tenant identity, data isolation, role permissions, configuration, plan quotas, billing, audit, import, export, and deletion. Design self-service registration, activation, upgrade, and suspension. Provide migration, staged release, backward compatibility, monitoring, backup, and disaster recovery across tenants. Inventory every hard-coded company name, process, field, and permission; changing the logo is not productization.
The financial model includes product engineering, cloud and third-party APIs, onboarding, support, sales, refunds and bad debt, and continuing maintenance. Calculate gross margin from monthly customer revenue less variable service and infrastructure cost, then evaluate acquisition cost, payback period, churn, and renewal. If every new customer requires substantial custom work, the business behaves more like project services than scalable SaaS.
Wavesteam helps compare an internal tool, standardized service, and independent SaaS, then uses paid evidence to recommend whether productization should proceed. If it does, the SaaS is scoped and priced as a new project; the remaining budget from the internal system cannot fund unlimited conversion. Our Transparent Delivery Standard explains the original project's scope, change, and asset boundaries.
References
- The AWS SaaS Lens covers multi-tenant identity, isolation, operations, and architecture without requiring the use of AWS.
- OWASP ASVS supports identity, access-control, data, and API testing; tenant isolation still needs dedicated design.
- The Wavesteam Transparent Delivery Standard describes scope, change, and asset boundaries for custom work.
This does not predict that a particular product will fail. It means SaaS must be treated as a separately validated business, not a small feature added to the original project.