01/
Buyer, customer, and user
Separate who pays, who administers, and who uses the product day to day; they are often three different people.
SaaS Product Development
SaaS product decisions shaped around customers, roles, and operations.
Start with the customer model
Make the product model clear before calling
the software SaaS
SaaS is not a synonym for any browser application with login. We start by establishing whether a repeated, multi-customer model is actually the requirement.
TIER01
Single-organisation system
TIER02
Configured existing platform
TIER03
Bespoke connected system
TIER04
Multi-customer SaaS product
Customer and access model
Start with who receives value—and who
operates the product
Account, role, and access decisions shape the product before a line of code is written.
02/
Account and organisation model
Define how accounts, teams, and memberships are structured before touching data models.
03/
Roles and data boundaries
Establish what each role can see or change, and where one customer's data must never reach another.
04/
Commercial and access model
Free access, trial, seats, credits, usage, or contracts each shape the product differently.
Product boundary
Build the repeated customer workflow before expanding
the module list
The repeated customer workflow is the product. Everything else exists to support that one path to value.
(001)
The repeated workflow is the product, not a feature
Everything else — admin tools, billing, onboarding — exists to support one core, repeatable path to value.
(002)
Onboarding is part of the product
Getting a new customer or team to first value is a designed path, not an afterthought.
(003)
Administration is operating software
The tools operators use to run the product for customers deserve the same rigor as customer-facing surfaces.
(004)
Entitlements are testable, not assumed
Plan, seat, and usage rules become explicit, verifiable product behavior once the commercial model is approved.
Technology decisions
SaaS
architecture stack
The stack follows the requirement, not the other way round. These are the categories this engagement typically has to decide.
01
Next.js App Router
02
Node.js / Go
03
PostgreSQL (Multi-Tenant)
04
Stripe & Paddle Billing
05
Redis & BullMQ
06
WorkOS / Auth0 SSO
Possible scope
Build the operating tools behind
the customer experience
The exact responsibility depends on the customer and commercial model. None of the following should be assumed automatically.
Account, organisation, and membership designRoles, permissions, and data boundariesCommercial and entitlement modelOnboarding and first-value path
Core repeated workflow implementationCustomer-facing surfacesOperator and admin toolingData isolation and configuration
Billing or usage provider integration where approvedNotifications and lifecycle eventsSupport and export toolingRelease and monitoring for a multi-customer product
Repository and environment access as agreedOperating and configuration documentationHandoff or continuation decisionRoadmap boundary for the first release
SaaS architecture decisions
Translate the commercial model into access rules the
product can enforce
Every SaaS decision trades something specific for something else. The useful choice is the one whose reason is understood.
01
How is customer data isolated?
Isolation strategy follows the data-sensitivity and scale requirements of the actual commercial model, not a default preference.
02
Does the product need subscriptions at all?
Not every SaaS product needs recurring billing; credits, contracts, and free access are equally valid models.
03
How much can customers configure themselves?
More self-service reduces operator load but increases the product surface that must stay correct.
04
How much of the customer lifecycle ships first?
A first release can support the core workflow and defer lifecycle edges like plan changes or offboarding.
Inspectable outputs
Leave a usable product and a record of
how it works
Deliverables should make the customer and commercial model visible and testable.
01/
Customer and commercial model record
Account structure, roles, and access model in a form the team can build against.
02/
Working product
The core repeated workflow and minimum operator controls, demonstrated end to end.
03/
Entitlement and data-boundary evidence
Proof that the approved commercial and access rules actually hold in the product.
04/
Access, documentation, and transition
What is needed to operate or continue the product after this release.
Delivery and engagement
Choose SaaS when the customer model changes
the product decisions
The starting engagement should resolve customer-model uncertainty before committing to build scope.
01
BOUNDED DISCOVERY
Customer-model definition
A bounded stage to resolve account, role, and commercial-model questions before build scope is set.
02
FIXED-SCOPE MILESTONE
Defined SaaS build
A project-shaped engagement for the first coherent multi-customer release.
03
STAGED RELEASES
Staged rollout
Release the core workflow first, expanding admin and lifecycle surfaces in later stages.
04
CONTINUOUS CADENCE
Ongoing product engineering
Continued responsibility once the SaaS product has an active roadmap.
Fit and routing
Use the service
that owns the defining condition.
SaaS Product Development is the right starting point when a repeated customer model defines the work. A different service may own the wider need.
01/ ALTERNATIVE
Custom Software Development
Choose this when the system serves one organisation rather than many customers.
02/ ALTERNATIVE
MVP Development
Choose this when the primary decision is what to test first, not the full product model.
03/ ALTERNATIVE
Web Application Development
Choose this when the browser surface is the defining question, not the customer model.
04/ ALTERNATIVE
Ongoing Product Engineering
Choose this when the SaaS product already exists and needs continued roadmap responsibility.
Frequently Asked Questions
SaaS Product Development questions,
answered clearly.
Technical delivery and architecture details. Key decisions regarding code quality, integrations, and handoff rituals.
No. SaaS depends on a repeated customer and operated-product model. Login, cloud hosting, roles, an admin dashboard, or payment integration alone do not establish that model.