SaaS development for a product the second customer can use without a fork.

A SaaS product serves many customer accounts from one maintained product. In addition to the user workflow, it needs tenant isolation, account administration, onboarding, plans, entitlements, billing, support access, usage controls, and product operations. A web application used by one organisation may not need those layers.

Use MVP development when the main risk is whether users want or complete the core job. Use SaaS development when the job is validated and the next risk is serving customers repeatably through one product. A SaaS MVP can include both decisions, but the validation question should still control the first scope.

The choice depends on customer risk, data residency, expected scale, operating cost, support model, and procurement needs. Shared tables, separate schemas, and separate databases each trade isolation against operational complexity. We document the threat and cost model before choosing, rather than assigning one model to every industry. Whichever model you choose, demand three deliverables in the contract: version-controlled database migrations, server-enforced tenant isolation on every query (not just hidden in the interface), and integration tests covering authentication and payments. The classic failure is one customer viewing another's invoices by editing an ID in the URL.

Mobile apps, migrations, enterprise identity, regional hosting, complex billing, usage metering, regulated evidence, and many integrations increase the scope. The first phase is priced after the product and tenant boundaries are defined, at a fixed cost agreed before development starts.

The client owns the project-specific code and controls the repository, cloud accounts, data, and provider subscriptions. Open-source libraries and external SaaS services remain subject to their own terms. We document the architecture and operating paths so another competent team can continue the product.

Core flow, authentication, and one way to pay. Teams, multi-account access, tiered billing, and seat management do not belong in an MVP: they are the fastest way to turn a focused release into a platform project. Each addition should earn its place by unblocking a paying customer, not a hypothetical one.

Three red flags: the agency keeps the code until a final payment that was never clearly agreed, the scope is a paragraph instead of a document, and changes are billed at a standard rate with no quote requirement. Expect work-for-hire ownership, milestone-based IP transfer, a written scope with acceptance criteria, and a change process that requires your written approval before work starts.

Sign up like a customer. Create two separate accounts and confirm neither can see the other's data. Try editing IDs in URLs, the oldest trick in the book. Run the core flow end to end, attempt a failed payment, invite a team member, cancel. Agree what done looks like for each workflow before it is built. If the team cannot show you tenant isolation working, they have not built it.

Name the target countries, customer types, data roles, provider chain, hosting and transfer boundary, accessibility target, languages, billing providers, payment authentication, tax advisers, support model, and procurement evidence. RaftLabs builds the approved technical and operating requirements; the client retains legal, tax, privacy, and market approvals.

Choose the pricing model that matches your cash and feedback needs, not a launch-day spike. Lifetime deals buy early cash and feedback at the cost of future recurring revenue; subscriptions protect MRR but need more customers to cover costs. Either way, keep product access (entitlements) separate from payment events so failed payments, refunds, plan changes, and pricing experiments stay manageable. That separation is part of what we build.

Define the allowed configuration up front: roles, data imports, invoice terms, and plan options that expected variation can absorb. We release to a small customer group first (see Process: Onboard controlled cohorts), make provisioning, configuration, imports, and activation a visible product path with recoverable errors, and only expand once onboarding is repeatable without engineering help.