Building software people subscribe to
SaaS development builds software sold by subscription. Beyond the product itself it requires multi-tenancy so customers' data stays separated, subscription billing with the failure cases handled, onboarding that gets people to value, and the operational tooling to run it once people depend on it.
The product is the visible half of a SaaS build. The other half is everything required to charge for it reliably and operate it once customers depend on it. And that half is consistently underestimated, because it is invisible in a demo and unavoidable in production.
The plumbing is where SaaS projects overrun. Multi-tenancy decided late means retrofitting data isolation into a schema that assumed one customer. Billing built for the happy path has no answer for a failed card, a mid-cycle upgrade, a refund or a currency change. Onboarding is left until the end, so trials expire before anyone reaches the thing that would have convinced them. And nobody built the internal tools support will need, so every customer issue becomes a developer task.
When this work makes sense
Questions worth asking any supplier
Is multi-tenancy decided before the schema is written? Retrofitting isolation is painful and risky.
Does billing handle failed payments, upgrades, downgrades and refunds, or only successful signups?
Is onboarding designed, or assumed? Most trial users leave before reaching the value.
What internal tooling will support need? Without it every issue becomes a developer interruption.
What is the smallest version that tests the proposition? Building the full vision first is the common expensive mistake.
Deliverables
Multi-tenant architecture with data isolation settled before implementation
Subscription billing integrated, including the failure and change cases
Authentication with team accounts, invitations and role permissions
Onboarding designed toward a defined activation moment rather than a feature tour
Internal admin tooling so support can act without a developer
Usage metering where the pricing model depends on it
Monitoring, error tracking and backups from the start rather than after the first incident
Built with
Process
SaaS builds settle the tenancy model before any feature is written, shared schema, separate schemas, or separate databases. That decision determines how data is isolated, how backups and restores work per customer, and what happens when one customer asks for their data to be exported or deleted. It is the single most expensive thing to change later, and the one most often deferred because it is invisible in the first demo.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
MVP, full build, or productising on an existing platform
MVP
Fits: Testing whether people will pay before building the whole idea
Limits: Deliberately incomplete; needs honesty with early customers about that
Full build
Fits: Validated propositions with a known customer need
Limits: Largest investment before any revenue arrives
Building on an existing platform
Fits: Getting to market quickly where the platform fits the model
Limits: Constrained by the platform, and migrating off it later is a rebuild
Case studies
No published SaaS case study. Product metrics are commercially sensitive and we will not publish approximations.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
What is multi-tenancy and why does it matter?
It is how one application serves many customers while keeping their data separated. The model you choose determines isolation, per-customer backup and restore, and how data export or deletion requests are handled. Deciding it after the schema exists means rewriting the schema.
Should we build an MVP first?
If there is genuine uncertainty about whether people will pay, yes. If the need is already proven, you are automating something you currently deliver manually and customers are asking, you are building rather than testing, and an MVP is the wrong frame.
Which payment provider should we use?
Stripe for most international products; Razorpay where Indian payment methods matter. The determining factors are the markets you sell into, the currencies you need, and settlement. It is worth deciding early, because billing logic is not trivially portable.
How do we handle failed payments?
Deliberately, with retry schedules, notifications, a grace period and a defined point at which access is restricted. Most of these cases come from the payment provider as webhooks, and they need handling rather than logging.
What does it cost to run a SaaS product?
Hosting, database, payment processing fees, email, error tracking and monitoring, most of which scale with customers. We size these during scoping, because unit economics that only work at a volume you have not reached is a discovery best made early.
Do we need SOC 2 or ISO certification?
It depends who you sell to. Enterprise buyers frequently require it; small business customers rarely ask. It is a substantial programme rather than a technical feature, and we would build with the relevant controls in mind rather than claiming any certification ourselves.
How do we handle a customer asking us to delete their data?
With a process that actually works, which depends on the tenancy model chosen at the start. Shared-schema architectures make per-customer deletion a careful query rather than a simple operation, and backups complicate it further since deleted data persists in them until they rotate. If you sell into markets with data protection regimes that grant deletion rights, this is a requirement rather than a courtesy, and it should shape the architecture rather than be retrofitted.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.