Loading
Product line
Tenancy and isolation, a subscription lifecycle that survives a failed payment, self-serve onboarding, and an internal admin console your own team can actually work in.
SaaS product · in the build
Anatomy
A first release can be narrow in features and still has to be complete in the loop from signup to payment to usage. These are the four parts of that loop.
Whether tenants share a schema with a discriminator, hold a schema each, or hold a database each — decided against your real compliance and scale position, not by preference. Every query is scoped at the data layer so isolation does not depend on a developer remembering a filter.
Trial, active, past due, paused, cancelled, reactivated — as an explicit state machine with webhooks reconciled against your own records. The failure paths are the product: a failed card must degrade access predictably, not lock a paying customer out on a Friday.
Signup, email verification, workspace creation, seat invitations, roles, and the first-run path that gets one person to something useful before they lose interest. Self-serve where it can be, assisted where the product genuinely needs it.
The internal surface where your own team impersonates safely, inspects a tenant's state, adjusts a plan, replays a webhook and reads an audit log. Its absence is the single most common reason a launched SaaS product cannot be supported.
Why it matters
The same artefact described above, read as outcomes rather than as engineering. Each one follows directly from a decision already explained on this page.
Tenant isolation enforced at the data layer, not just in application code, means a missed filter in a new feature can't leak one customer's records into another's screen.
Billing state reconciled against the provider on a schedule turns a missed webhook into a fixed discrepancy instead of a customer who quietly stops paying or loses access.
An admin console built as part of the product, not bolted on afterwards, lets your own support team answer a ticket without an engineer opening a database client.
Support staff can see what a customer sees without ever asking for their password, removing the single most common support-side security risk.
Tenant export and deletion built in from the start avoids the far larger engineering bill of retrofitting it once thousands of tenants already share the same tables.
Key features
Behaviour of the built thing, not a list of adjectives. Every entry below is something you can check after delivery.
The demo is the easy part. What turns a demo into a product is the half nobody puts in the pitch deck: how tenants are isolated, what happens when a card fails, who can invite whom, how a trial converts, and whether your own team can answer a support ticket without opening a database client. That half is what we build, and it is why this line exists separately from web applications.
Technology
A stack we actually run in production. Where your team already has a preference and it is a reasonable fit, we work in yours instead of arguing for ours.
Runs on
Before we quote
Each of these three is a fork in the architecture. Taking the wrong branch is survivable; taking it silently is not.
A shared schema with row-level security is the cheapest to operate and the right default for most products. A schema or database per tenant costs more to run and migrate, and earns that cost when a customer contract demands physical separation or when one tenant's data volume would distort the rest. The decision follows your compliance position and your largest expected tenant, and it is written down with the reasoning.
This is a product decision disguised as a technical one. Immediate lockout loses customers over an expired card; indefinite grace gives the product away. We implement a stated sequence — retry schedule, notification, read-only degradation, then suspension — so the behaviour is deliberate and your support team can explain it.
Self-serve signup implies an onboarding path, a support surface and abuse controls, all of which are real work. Early on, assisted onboarding with a small number of customers often teaches more and costs less, and the self-serve path can follow once you know which step people get stuck on. We will argue for whichever fits where the product actually is.
Pricing and engagement
There is no fixed price for saas products because the scope varies by how tenancy is isolated and how much of the billing and admin surface already exists — here is how the work is actually engaged, and which of these usually fits this product line.
For work where the requirements are genuinely settled. A written scope, a phased plan and a price we hold. Best for a defined build, a migration, a security engagement or a design phase.
Named engineers at a monthly rate, working on your board and in your repository. The right shape when the roadmap is still moving, which is most products after their first release.
Ongoing maintenance, monitoring response, dependency updates and a block of hours for changes, under a written arrangement agreed before launch rather than during an incident.
Where it is used
Sectors where we are asked for this artefact most often. It is a statement about the fit of the shape, not a client list.
How the work is run
This page describes the artefact. Scope, delivery model and engagement terms live on the service pages, which is where they belong — follow whichever applies rather than reading it twice.
Questions
Yours. We are an engineering partner, not a co-owner taking equity, and the repository, the cloud account, the billing account and the customer relationships are yours throughout. We will say plainly when we think an idea has a product problem rather than a software problem, because building a well-engineered product nobody buys is a bad outcome we would rather avoid than invoice.
It depends on where your customers are and how you invoice. Razorpay and its subscription tooling fits domestic Indian collection well; Stripe fits international card revenue and complex plan structures. Both are integrated the same way on our side — an idempotent webhook path reconciled against our own records — so the choice is commercial rather than technical, and switching later is unpleasant but survivable.
Yes, and it starts with a read rather than a rewrite: whether it builds from a clean checkout, how tenant isolation is actually enforced, whether billing state matches the provider, whether backups have ever been restored, and where the authorisation checks live. That produces a written risk list ordered by what would hurt most, and the first work is usually two or three items from the top of it rather than a redesign.
By building for it early enough that the answer is yes. If the codebase can deploy as a single tenant from the same repository and the same infrastructure definitions, a separated instance is an operational cost rather than a fork. What we avoid is the fork: two diverging copies of a product is a maintenance problem that compounds with every release.
Probably not to launch, and possibly later if you sell to enterprises that ask. What we do from the start is build the things those audits look for anyway, because they are good practice regardless: access control, audit logs, encrypted data at rest and in transit, backup and restore that has been tested, and a documented deployment path. That means a later certification is a process exercise rather than a rebuild. We are not auditors and do not certify anyone.
Also in products
Web platform
A signed-in system in the browser: records, roles, state changes and an audit trail behind them.
Mobile product
An installed app for iOS and Android, built to work on a bad connection and to survive a store review.
Describe what the finished thing has to do and who has to use it. We will tell you which parts of a saas products build are the expensive ones in your case, and where a smaller first release would get you most of the value.
What happens next
