Most SaaS products are rewritten between customer five and customer fifty — not because the code was bad, but because tenancy, billing and permissions were decided in a hurry. We decide them first, in week one, while they are still cheap.
MVP in 8–12 weeksRow-level tenant isolationFull IP transfer
SaaS product development is building software sold as a subscription and operated by its maker rather than installed by the customer. Canopus builds the parts that make that model work — multi-tenant data isolation, subscription billing, role-based access, usage metering, tenant onboarding and the admin tooling your own team needs to run it.
Multi-tenant PostgreSQL with row-level security — the same schema runs 5 tenants or 500 without a rewrite. Isolation is enforced by the database, not by remembering to add a WHERE clause in every query, because the day someone forgets is the day one customer sees another customer's data.
Where a contract genuinely demands physical separation — a bank, a health system, a government tender — we run those tenants on dedicated databases from the same codebase and price it as an enterprise tier. What we don't do is commit the whole product to database-per-tenant because one prospect asked, then discover at forty customers that every schema migration is a forty-step deployment.
Founders scope the product. What sinks the timeline is everything around it — the machinery that turns an application into a business.
Stripe Billing wired properly: plans, trials, proration on mid-cycle upgrades, dunning for failed cards, tax through Stripe Tax, and an entitlement table in your own database so a webhook delay never locks out a paying customer.
Not "admin and user". Real organisations have owners, billing contacts, team leads, read-only auditors and support staff who need impersonation with an audit trail. Getting this wrong blocks your first enterprise deal.
The console your own team runs the business from — which tenants are active, which are about to churn, who is over their limit, and what a support agent can do at 2pm without a developer.
Timelines assume one core workflow done properly. They move if your product needs regulated data handling or a hardware integration.
Live billing and real customers in the first release. Built to be extended, not thrown away.
The version that survives a sales team selling it. Most clients land here.
What procurement and security review at a large customer will actually require.
Every tier includes IP transfer, deployment to your own cloud account, and a documented handover. None of them include a Canopus runtime, a per-tenant fee or a component you have to keep licensing from us.
In roughly this order, and roughly at these points. Knowing the sequence is what lets you not build for it on day one.
None of these are emergencies if the foundation anticipated them. All of them are emergencies if it didn't — which is why we spend week one on tenancy, identity and the billing entitlement model rather than on screens.
Tenancy, billing and enterprise requirements set it, in that order — how many tenant-facing workflows are in the first release, how complicated the billing shape is — flat plans versus per-seat, metering and overage — and whether enterprise requirements like SAML/OIDC single sign-on, audit logging and data residency belong in release one or release two. The driver is rarely the feature list; it's the operational surface: billing edge cases, tenant provisioning, support tooling and the reporting your own team needs to run the business. Tell us who buys it and what they pay for, and you get a written estimate broken down by workflow rather than one number for the whole build.
Eight to twelve weeks to a production MVP with live Stripe billing taking real payments. That assumes one core workflow done properly rather than five done partially. Adding SSO, a public API and SOC 2 evidence collection typically pushes the second release out another eight to ten weeks.
Shared schema with row-level isolation for almost everyone. It keeps migrations to a single operation and lets one team support hundreds of tenants. Database-per-tenant is right when a contract demands physical separation or a specific data residency — and we mix the two rather than committing the whole product to the expensive option.
Stripe Billing by default — subscriptions, proration, trials, tax via Stripe Tax and a customer portal you don't have to build. Paddle where you want a merchant of record handling global VAT. Razorpay or PayTabs where the market is India or the GCC. We build the entitlement layer in your own database rather than reading plan state from the provider on every request.
You own it. Full IP assignment on payment, including infrastructure-as-code and CI configuration. There's no Canopus runtime, no per-tenant fee to us and no component you'd have to license to keep operating. If you raise funding, your investors' technical due diligence will find a clean repository.
Yes. We audit first — tenancy model, billing correctness, migration safety, security exposure — and give you a written plan before touching production. The most common finding isn't bad code; it's that tenant isolation was implemented in application logic only, with no database-level backstop.
We build the technical controls auditors ask for — audit logging, RBAC, encryption in transit and at rest, access reviews, backup and restore evidence, change management through CI. We're not an audit firm and we don't certify you; we make the evidence exist so your auditor has something to sample. More on what we do and don't cover.
Yes — most SaaS clients keep us on a monthly retainer covering monitoring, incident response, dependency patching and continued feature delivery. It's the same team, so there's no handover tax. Dedicated teams and AMC covers how that's structured.
Those two answers determine the tenancy model, the billing shape and half the architecture. Send them over and an engineer replies within one business day with the trade-offs as we see them.