At a glance
What you need to know.
A SaaS product needs more than hosted screens. It must deliver a useful job, isolate customer access, explain account and billing states, and remain supportable after launch. Choose the smallest coherent product scope and validate its complete lifecycle before widening the feature list.
Choose a customer and a complete first job
Identify who buys, who uses and who administers the product. These may be different people. Describe the task that makes the application worth returning to, its current alternative and the evidence that would show improvement. A narrow first release should still let a user finish that task: enter information, act on it and find the result later. Avoid splitting essential usability across future phases. Record assumptions about demand separately from the features the team knows how to build.
Define tenant and record ownership before adding teams
Decide whether an account represents a person, organization or workspace and whether a user can belong to several. Model invitations, role changes, ownership transfer and removal. Enforce tenant scope on the server for every relevant read and write, including exports and background jobs. Test with two organizations and attempts to reference the other's records. A tenant selector in the interface is not isolation. Dedicated and shared infrastructure models have different cost and operating tradeoffs; choose against actual requirements.
Make access and subscription states explicit
Define which capabilities a trial, active subscription, expired subscription and cancelled account may use. Separate a billing provider's event from the product's entitlement decision. Specify handling for delayed or repeated billing events and reconcile with authoritative provider records. Avoid hard-coding a customer's plan from browser input. Explain to users what happens to records when access changes and how they can export permitted data. Test the payment lifecycle in the appropriate test environment before enabling real transactions.
Design activation and support into the product
Help a new user reach the first useful result with the minimum required setup. Provide empty states, realistic examples and validation that explains how to recover. Distinguish an action that saves a record from an action that sends a notification or changes an external system. Give administrators an understandable path for invitations and access changes. Establish support intake, response ownership and visibility into failed operations before a pilot. Do not invent a response-time promise simply because a support link exists.
Verify the full lifecycle in a deployed environment
Exercise signup, login, logout, password or identity recovery, tenant switching, record creation and export with intended user roles. Verify persistence across reloads and deployments. Test subscription changes, duplicated provider events, revoked access and dependency outages. Check what an operator can inspect without exposing another customer's content. Define backups and a restoration procedure for authoritative data. Build success and an available homepage are necessary signals, but neither establishes that these authenticated paths work.
Expand from observed use and known operating limits
Pilot with a clear scope, known limitations and an accountable product owner. Track completion of the core job, correction effort, retained use and support burden instead of relying only on registration totals. Estimate cost per active customer using compute, data, external services and operating time. Agree the release, rollback and schema-change procedure. A prototype can inform these decisions without being advertised as supported production software. Publish availability and features only to the extent that current implementation and operating evidence support them.
Before you start.
- Name the buyer, administrator and repeat user job.
- Model tenants, invitations and server-enforced record boundaries.
- Define billing states and product entitlements separately.
- Test onboarding, persistence, recovery and account removal.
- Verify provider event handling and cross-tenant access attempts.
- Assign product operations, backup recovery and pilot acceptance.
Common questions.
Can an internal tool become a SaaS product?
Yes, but the transition introduces customer boundaries, onboarding, account lifecycle, support, commercial states and operating responsibilities. Reusing the interface can help, while assumptions about trusted users and shared data often need redesign and verification.
What belongs in a SaaS MVP?
The complete core job and the controls required to use it safely within the agreed pilot. Optional features can wait. Tenant isolation, correct authorization, recoverable data and understandable account states should not be postponed when the pilot already depends on them.