Accounts and workspaces
Sign up, verify, create a workspace, invite teammates. One person can belong to several workspaces without a second account.
CASE STUDY
Example buildSaaS ProductSaaS Subscription Starter
Sign-up, workspaces, plans and recurring billing — the unglamorous half of a SaaS product, built once and properly.
- Type
- Multi-tenant SaaS
- Build time
- 14–18 weeks
- Platforms
- Browser, any device
- Starts at
- ₹1,40,000*
This is an example build. Tavzuran is a new studio with no client work to show yet. This page describes how the project would be scoped and built — the same thinking you would get on a real one. Nothing here is a past client, and no number on this page is a result.
The price follows the feature list. The number above buys everything scoped on this page. Take features out and it comes down — the shortest route to a smaller number is a shorter list, and deciding what to drop is what the free call is for.
THE SITUATION
What's actually broken.
A founder has a genuinely good idea for a tool and a clear first customer. What stands between them is the part that is identical in every SaaS product ever built: accounts, workspaces, invitations, roles, plans, trials, card failures and invoices.
None of that is the product. All of it has to be right, because getting billing or data isolation wrong is the kind of mistake that is discovered by a customer rather than by you.
Every customer needs their own separated data
Billing, trials and downgrades all have to agree
One customer's heavy usage slows everyone down
Adding a teammate should not need a developer
VERSION ONE
What we'd build first.
Every item here earns its place by being something a real user would miss on day one.
Roles that actually restrict
Owner, admin and member, enforced on the server. A permission check that only hides a button is not a permission check.
Plans and trials
A free trial with a real end date, paid plans, upgrades, downgrades and the awkward states in between — expired card, failed renewal, cancelled but still inside the paid period.
Recurring billing
A payment provider handles the card. We handle what happens to the customer's access when a charge succeeds, fails or is refunded.
Tenant isolation
Every query is scoped to a workspace at the data layer, not by remembering to add a filter. This is the part that must not be a convention.
DELIBERATELY NOT IN V1
What we'd leave out.
Not because these are bad ideas. Because each one is designed better once the first version has told you something.
- Usage-based and metered pricing. Start with flat plans; metering is a project on its own and is easier once you know how people use it.
- SSO and SAML. Enterprise customers ask for it. You do not have enterprise customers on day one.
- An admin back-office with everything in it. Start with the three screens support actually needs.
UNDER THE HOOD
How it's put together.
- App
- Next.js, so the marketing pages and the product share one codebase and one deployment
- Backend
- Node with Postgres, workspace isolation enforced with row-level security
- Billing
- Stripe or Razorpay subscriptions, driven entirely by webhooks rather than by what the browser reports
- Auth
- Email and password plus Google, with sessions that survive a server restart
- A transactional provider for invites, receipts and failed-payment warnings
HOW IT RUNS
Week by week.
-
01
Week 1
The tenancy model: what a workspace owns, what happens when someone is removed, what a downgrade takes away.
-
02
Weeks 2–7
Accounts, workspaces, invitations and roles.
-
03
Weeks 8–14
Plans, trials and billing, including every failure path.
-
04
Weeks 15–18
Your actual product feature, on top of the foundation.
THE HARD PART
Billing state and access state must never disagree
Every build has one problem that decides whether the rest of it matters. This is that problem, written out.
The product features are yours. The part that goes wrong is the relationship between what the payment provider believes and what your application allows, because those are two systems and they will drift.
The rule that prevents most of the pain: access is decided by what the provider's webhooks have told you, never by what the browser reported after a checkout. A user who closes the tab mid-redirect has still paid. A card that fails on renewal at 3am has still failed, whether or not anyone was looking.
Then there are the states nobody designs for until a customer hits one: cancelled but paid until the end of the month, downgraded with more data than the smaller plan allows, a failed payment inside its retry window, a refund after the period started. Each needs a decided answer. Most of the support burden in a young SaaS comes from these, not from the actual product.
BEFORE A PRICE EXISTS
What we'd ask you first.
A quote given without these answers is a guess. These are the questions that actually move the number.
- 01Who is the first paying customer, and what do they need on day one?
- 02Per-seat or flat pricing — and what happens when a team shrinks?
- 03How long is the trial, and what does an expired trial still allow?
- 04What must a downgraded customer lose, and what must they keep?
- 05Are there data-residency requirements from your target customers?
AFTERWARDS
How we'd know it worked.
Agreed before the build starts, so there is something to judge it against other than whether it looks nice.
- Access always follows the webhook, and no one has ever edited the database by hand to fix a subscription.
- Trial-to-paid conversion is a number you can see, not a guess.
- A failed renewal warns the customer before it cuts them off.
- Every workspace's data is provably isolated, tested rather than assumed.
BEFORE YOU START
Worth knowing.
Payment providers charge per transaction and most take a cut of each subscription. That is billed to you by them, not by us, and it scales with your revenue rather than with the build.
Websites and apps start at ₹20,000*. Final pricing depends on features and project scope. Third-party costs — cloud hosting, domains, external libraries, APIs, app-store fees and any other paid service — are billed separately and are not included.
KEEP LOOKING
Other example builds.
Website
Business Website That Converts
A fast, mobile-first site that turns visitors into enquiries — and that you can edit yourself.
Read the case study Custom SoftwareInventory & Billing for Retail
Stock that matches the shelf, GST-ready bills in seconds, and an alert before a fast seller runs out.
Read the case study Web AppClinic Appointments & Records
Appointments, patient history and prescriptions in one place, with reminders that cut the empty slots.
Read the case studyWant this built for your business?
Tell us what you're thinking. We'll figure out the next step together.
Free 20-min idea call · No obligation