Most SaaS projects do not fail on engineering. They fail because eleven months went into features nobody had agreed to pay for. We build the smallest version that can charge money, put it in front of real users, and let what they do decide the roadmap.
SaaS product development covers the architecture, build and launch of a multi-tenant subscription application: tenant isolation, authentication, role-based access, subscription billing, usage limits and product analytics. An MVP typically takes ten to sixteen weeks from definition to a product taking real payments.
Kickoff to a live product taking real payments, across the SaaS builds we have shipped.
Working software on a staging URL every fortnight — no month-long silences.
Across our marketing engagements, including the launch campaigns that put the first users into these products.
Repository, cloud account, Stripe account and analytics registered to you, which matters at diligence.
One-page product definition
ADR and fixed-price scope
Tested Figma prototype
Fortnightly deployable build
Beta findings and priority list
Live product and growth retainer
The pattern is consistent. A long build against a full specification, a launch, and then the discovery that the feature the roadmap was organised around is not the one anyone would pay for. The engineering was competent. The sequence was wrong.
The architecture decisions taken in week two decide what the product can charge for in year two. These are the ones that matter, framed by who is building.
A specification written from competitor feature lists, funded to the last rupee, with no room for what the first fifty users teach you.
A scoped MVP that charges money on day one, plus a deliberate reserve for the two months after launch when the real roadmap appears.
A service delivered manually to forty clients, profitable but capped by headcount, with the process living in the founder's head.
The repeatable eighty percent turned into software, the rest stays human — and pricing moves from hours to seats.
A tool built for one department, now wanted by three, with no tenancy model, permissions or billing to support that.
A proper multi-tenant rebuild with roles, quotas and per-department reporting from the start.
Two-sided liquidity problems disguised as feature problems, plus payments and payouts nobody has designed.
Supply-side tooling first, escrow and payout flows designed properly, and the demand side launched only when there is something to demand.
A global product that does not handle GST, UPI, WhatsApp or Indian address formats, so every customer needs manual help.
Localisation as a first-class feature: GST-compliant invoicing, UPI and Razorpay, WhatsApp notifications, regional formats.
A thin wrapper around a model API with unpredictable costs, no evaluation and no defensibility.
Retrieval over your own data, cost controls per tenant, evaluation harnesses and a fallback when the model is down — see [AI Automations](/services/ai-automations).
Almost everything in a SaaS product can be changed later. These four cannot be changed cheaply, so they get decided deliberately in the first fortnight rather than discovered in the first audit.
Shared schema with a tenant column, schema per tenant, or database per tenant. The choice sets your isolation guarantees, your migration pain and what you can promise an enterprise buyer. Retrofitting it means touching every query you have written.
Roles, organisations, invitations, SSO. Enterprises will ask for SAML eventually; building on a provider that supports it costs nothing now and saves a rebuild later.
Plans, seats, usage, trials, proration, dunning, and reconciling webhooks against your own records. Bolted on late, billing is the most bug-prone system in the product.
Product analytics from the first release, so activation, retention and feature usage are observable. Without it, roadmap decisions are opinions with a deadline.
The one job the product does, the user it does it for, and what the first paid plan includes. Written down and short enough to argue with.
Tenancy, auth, billing model, data model, hosting — each with the reasoning. Diligence teams and future engineers both read this.
Signup, onboarding, the main workflow and the upgrade path, designed in Figma. Onboarding is a product surface, not a support article.
Next.js and Postgres with row-level security, organisations, roles, invitations and an audit log.
Stripe or Razorpay with plans, trials, seat counts, usage limits, webhook reconciliation and a customer-facing billing portal.
Event tracking on activation and the core loop, funnels, and a retention view — so week four is a number rather than a feeling.
Internal tooling to impersonate, adjust limits, refund and debug. Building it late means your support runs on database queries.
Landing page, pricing page, tracking and the launch campaign — the demand side is covered on [Performance Marketing](/services/performance-marketing).
Every tool on this list is one we have shipped and still maintain for a paying client. Nothing here is aspirational — if it is not in production somewhere, it is not on the page.
Chosen so a two-person team can ship weekly and a future in-house team can take it over.
Marketing site and application in one deployment, with the marketing pages static and the app dynamic.
Shared types between API and client, which is how a small team avoids an entire class of integration bug.
Row-level security is the cleanest tenant boundary available without running a database per customer.
Auth, storage and Postgres together — the fastest route to a production-grade MVP back end.
The systems that decide whether the product can actually take money reliably.
Subscriptions, metered usage, trials and dunning, reconciled against our own records rather than trusted from a redirect.
For Indian customers: UPI, mandates and GST-compliant invoicing that a CA will accept.
Push notifications and realtime state where the product has a mobile client alongside the web app.
Acquisition in GA4, in-product behaviour in an event tool, joined on the same user id so the funnel is continuous.
Most SaaS products that fail do not fail on engineering. They fail because eleven months went into features nobody had agreed to pay for, and the money ran out at the exact moment the team finally had real information.
It is the design, architecture and build of a multi-tenant subscription application: tenant isolation, authentication and roles, subscription billing, usage limits, an admin surface and the analytics that tell you whether any of it is working. The engineering is well understood. The sequencing is where the money is won or lost.
| Decision | Why it is hard to change later |
|---|---|
| Tenancy model | Retrofitting a tenant boundary rewrites every query you have written |
| Identity and permissions | Enterprise buyers ask for SSO; rebuilding auth to add it is painful |
| Billing and metering | Bolted on late, billing becomes the most bug-prone system you own |
| Event instrumentation | Without it, every roadmap decision is an opinion with a deadline |
Everything else in a SaaS product can be changed cheaply. These four get decided deliberately in the first fortnight — the tenancy question in particular is worked through in multi-tenant SaaS architecture.
Signup and onboarding that gets a stranger to value without a call. One complete workflow, done properly, for one user type. Payments, because a product nobody has paid for is a prototype with good manners. And analytics on activation, so week four tells you something.
Everything else — the second user role, the settings page with fourteen toggles, the integrations requested in deals that have not closed — belongs in phase two. The full argument, including the twelve-week schedule, is in MVP development.
If you are selling into India, localisation is a feature rather than a formality: UPI and mandates through Razorpay, GST-compliant invoicing a chartered accountant will accept, WhatsApp for transactional notification, and address and number formats that match how people actually write them. Global products routinely lose Indian customers to support burden created entirely by these gaps.
A product with no distribution is a hobby. We run the launch campaigns as part of the same engagement where clients want it — landing page, tracking, paid acquisition and the analytics joining the two, described on Performance Marketing. The advantage of one team is that the page the ads point at can change the same week the data says it should.
Every stage ends in something you can hold — a document, a build, a live account. If a stage cannot name its output, it is a meeting, not a stage.
Two days narrowing the idea to one job, one user and one paid plan. Most of the value of this stage is what gets removed.
Tenancy, auth, billing and data model decided and written down, with a fixed price for the MVP scope.
Signup, onboarding and the main workflow, prototyped and tested with five people from the target market.
A staging URL from sprint one. Billing goes in early, not last, so it is exercised throughout the build.
Ten to thirty real users, instrumented, with a weekly call. This is where the roadmap for the next quarter is actually written.
Public launch with the landing page, pricing page and tracking live, then a monthly retainer against what the data shows.
Everything here is part of the engagement at no extra cost. We do not itemise them on an invoice and we do not withhold them if you leave.
Two days narrowing the idea to one job, one user and one paid plan. Most of the value is in what gets removed, and you keep the document.
Tenancy, auth, billing and data model written down with reasoning. Investors ask for this and founders are rarely ready with it.
Activation and retention instrumented before launch, not added after the first board meeting asks for the number.
Impersonation, limits and refunds built in rather than left as database queries at 11pm.
The marketing site, pricing page and conversion tracking that the product needs on day one, included with the build.
Longer answers to the questions people ask before they hire anyone for saas product development.
Built by us, free, no signup, nothing uploaded to a server. Take them whether or not you ever become a client.
It is scoped on the number of workflows, user types and integrations rather than on a rate. An MVP that takes real payments is a defined project; a growth-stage build with SSO, integrations and an admin console is larger; an ongoing product team is monthly. Budget roughly two-thirds of what you can spend and keep the rest for after launch.
Tell us what you have now and what you are trying to reach. We will audit it and tell you what we would do, what it would cost and whether you need us at all. The audit is free and yours to keep.