SaaS Platform Development
SaaS Platforms Built for More Than the First Customer
A subscription product has to serve many organizations at once without letting any of them see another’s data, while supporting plans, roles, invitations, billing, and the administrative work of running a service.
Those requirements shape the data model. They are far cheaper to design in at the beginning than to retrofit after the tenth customer.
The problem
What This Work Addresses
These are the conditions that usually lead a business to this kind of engagement. Recognizing one or two of them is common; recognizing most of them is a strong signal.
A prototype built for one customer
Software that works for a single organization often has no concept of tenancy at all. Adding one later means revisiting every query, every route, and every stored file.
Entitlements enforced in the interface
When plan limits are checked only where buttons are rendered, the API remains open. Entitlements have to be enforced where the data is, not where it is displayed.
Billing state that disagrees with product state
Failed payments, downgrades, cancellations, and trials all change what an account may do. Without a defined mapping from billing status to access, the two drift apart.
No tooling to operate the service
Support cannot help a customer without a safe way to inspect an account. Building that in early prevents ad-hoc database access becoming the support process.
Usage that cannot be measured
If the product cannot count what a plan meters, pricing cannot be enforced, and neither the customer nor the business can see what is actually being consumed.
Scope
Typical Systems and Workflows
A representative range rather than a fixed menu. Most engagements deliver a subset, chosen during discovery.
Accounts and access
- Organization and workspace accounts
- User invitations and membership management
- Role and permission models
- Authentication, sessions, and account recovery
- Single sign-on where required
Commercial model
- Subscription plans and trials
- Entitlement and feature-gating logic
- Usage metering and quota enforcement
- Billing provider integration
- Upgrade, downgrade, and cancellation flows
Operating the service
- Internal administration tools
- Customer-facing reporting and exports
- Public and partner APIs with scoped keys
- Webhooks for customer integrations
- Monitoring, diagnostics, and support tooling
What We Evaluate Before Development
Deferring these questions is what makes software expensive to change later.
- What a tenant is: a company, a workspace, a location, or something else entirely
- Whether users may belong to more than one organization, and how context switching works
- The role model, and which permissions genuinely differ between roles
- Which limits are metered, how they are counted, and what happens when one is reached
- How billing status maps to product access, including failed payment and cancellation
- What data customers must be able to export, and what must be deleted on request
- Whether an API is part of the product from day one or a later addition
- Isolation requirements strict enough to justify separate databases per tenant
Typical Project Deliverables
What exists at the end of the engagement, beyond the running software itself.
- A multi-tenant data model with scoping enforced below the query layer
- Authentication, invitation, and role management flows
- Subscription and entitlement logic tied to a billing provider
- Usage metering with customer-visible reporting
- Internal administration and support tooling
- A documented API with scoped credentials and rate limits
- Automated tests covering tenant isolation and entitlement rules
- Deployment, migration, and environment documentation
Security and data
Security and Data Considerations
- Tenant scoping applied in a shared data-access layer so a new query cannot omit it
- Authorization decided server-side for every request, including API and webhook routes
- API credentials scoped per organization, revocable, and never logged
- Uploaded files stored under tenant-scoped paths with signed, expiring access
- Tests that specifically attempt cross-tenant access and expect failure
Integrations
Integration Considerations
- Billing webhooks verified by signature and processed idempotently
- Provider-side state treated as authoritative for billing, with reconciliation on mismatch
- Outbound webhooks to customers signed, retried with backoff, and observable
- Rate limits defined per organization rather than per IP address
- Versioning strategy agreed before the API has external consumers
Verification
The States We Design and Test
Software is judged on what it does when something is missing, slow, denied, or broken. These states are specified during design, not discovered in production.
- Loading
- First render is server-side where possible, so a customer sees their workspace rather than a spinner.
- Empty
- A newly created organization is guided toward its first meaningful action instead of being shown an empty table.
- Partial
- When a dependent service such as billing is degraded, the product continues to function and states clearly which capability is unavailable.
- Error
- Customer-facing errors are specific but never leak internal detail; the full context is retained server-side against a request identifier.
- Authorization
- Plan limits and role restrictions are explained where they are encountered, with a clear path to resolve them.
Process
How This Work Is Delivered
- 1
Tenancy and role definition
Agree what an organization is, how users relate to it, and which permissions actually differ before writing a schema.
- 2
Commercial model design
Map plans to entitlements and metered limits, and define how each billing state changes what an account may do.
- 3
Platform architecture
Design the isolation strategy, data-access layer, authentication model, and API surface together.
- 4
Incremental engineering
Build the core workflow first, then accounts, entitlements, and administration in reviewable stages.
- 5
Isolation and billing verification
Test cross-tenant access, quota enforcement, and every billing transition including failure and recovery.
- 6
Launch and iterate
Release with monitoring and support tooling in place, then prioritize from real customer usage.
Technology
Related Technologies
Selected per project against the workflow, data, security model, and expected lifetime of the software.
Application
- TypeScript
- React
- Next.js
- Node.js
Data
- PostgreSQL
- Row-level scoping
- Transactional migrations
Platform
- Cloudflare Workers
- Edge services
- Object storage
- Background jobs
Commerce and access
- Stripe
- OAuth
- Scoped API keys
- Webhooks
FAQ
Common Questions
- Shared database or a database per customer?
- A shared schema with enforced tenant scoping is the right default: it is cheaper to operate and to migrate. Separate databases are worth the overhead when a specific contractual or regulatory isolation requirement justifies it, and that decision belongs in discovery.
- Can you build on top of an existing prototype?
- Often, yes. We assess whether the current data model can carry tenancy and entitlements safely. Sometimes the fastest path is to keep the interface and rebuild the data layer beneath it.
- Do you handle payments directly?
- Payment collection is delegated to an established provider such as Stripe. We build the entitlement logic, webhook handling, and reconciliation around it; card data never touches the application.
- When should the public API be built?
- Design the API surface early even if it ships later, because an API added after launch tends to expose whichever internal shape happens to exist. Publishing it is a separate decision from designing it.
Related services
Custom Operational Software
Purpose-built internal and customer-facing systems designed around the processes, roles, records, and rules a business already runs on.
Automation and API Integrations
Connect approved systems, remove duplicate data entry, and coordinate work across platforms with integrations that are built for the ways APIs actually fail.
AI-Assisted Business Systems
Focused AI assistance inside specific workflows, with the review steps, limits, and audit trail the operation requires around it.
Describe the Workflow You Want to Improve
Tell us what your team manages today, where the process breaks down, who uses the system, and what a successful result would look like. That is enough to start a useful conversation.