Question 1

Should we build from scratch or can you work with our existing codebase?

Accepted Answer

It depends on what "existing codebase" means. If you have a prototype built in the last six months with a modern stack — Next.js, a relational database, a conventional folder structure — we can usually take it over, audit it, and build forward from there. We have inherited React codebases from solo founders, offshore teams, and no-code-to-code migrations, and the due diligence process (read the code, run the tests, identify the debt) takes about a week. If the codebase is more than two years old, written in a framework we do not support (Laravel, Ruby on Rails, classic Django), uses a data model that fights the feature roadmap, or simply lacks tests and documentation, a clean rebuild is almost always faster and cheaper over a 12-month horizon than a refactor. We give you an honest assessment during the Discovery stage — including a rough cost comparison between inheriting and rewriting — before you commit to either path. There is no incentive for us to recommend a rebuild unless the numbers actually support it.

Question 2

How do you approach multi-tenancy — row-level, schema-per-tenant, or database-per-tenant?

Accepted Answer

The right answer depends on your compliance requirements, your expected tenant count, and your pricing model. Row-level tenancy — where all tenants share one database and a tenant_id column enforces isolation — is the right default for most SaaS products launching under 500 tenants. It is cheap to operate, easy to query across tenants for analytics, and Postgres row-level security makes it production-safe when implemented correctly. Schema-per-tenant gives stronger logical isolation and makes per-tenant migrations possible, but it adds operational complexity fast: running migrations across 300 schemas is not trivial. Database-per-tenant is reserved for enterprise contracts where the buyer requires physical data isolation and is willing to pay the hosting premium for it — typically SOC-2 or HIPAA-adjacent use cases. We make this call during the Architecture stage, document the decision and its trade-offs, and build the tenancy model into every layer — from the ORM query helpers to the admin console to the billing metadata — so there is no ambiguity later about which tenant owns which row.

Question 3

What is your recommendation for real-time features — WebSockets, SSE, or a managed service like Pusher or Ably?

Accepted Answer

Server-Sent Events (SSE) are the right choice for one-directional streams where the client only receives — live feeds, progress bars, notification rails. They run over plain HTTP, require no special infrastructure, and work through proxies that WebSockets sometimes do not. WebSockets are right when you need bidirectional communication in the same connection — chat, collaborative editing, presence, multiplayer. We run WebSocket servers on Node with a Redis pub/sub layer for horizontal scaling; a single Redis instance handles fan-out to thousands of connected clients efficiently. Pusher and Ably are valid for teams that do not want to operate a WebSocket server — they handle the scaling, the connection management, and the edge infrastructure, and the per-message pricing is acceptable at low-to-medium volume. Above roughly 50 million messages per month, the managed-service cost exceeds what self-hosting costs on AWS. We default to self-hosted WebSockets on Node for most production SaaS builds and recommend Pusher or Ably for MVPs where time-to-ship matters more than cost optimisation.

Question 4

Which payment and subscription stack do you use, and how do you handle tax compliance?

Accepted Answer

Stripe Billing is our default for SaaS subscription management — it handles recurring billing, metered usage, proration on plan changes, dunning emails, and customer portal, and the API is the most battle-tested in the category. For founders who need to sell in more than one country without registering for VAT/GST in each jurisdiction, Paddle and Lemon Squeezy are merchant-of-record alternatives that handle tax collection and remittance on your behalf. That is a significant operational simplification — particularly relevant for bootstrapped or early-stage SaaS founders who are not yet ready to manage international tax compliance. The trade-off is less control over the checkout UX and a slightly higher processing fee. We build with Stripe by default and integrate Paddle or Lemon Squeezy when the merchant-of-record model is the better fit for the business. Whichever you choose, we implement webhook handlers, idempotency keys, and a local billing record so you have a queryable billing database that does not depend on a third-party API for revenue reporting.

Question 5

How do you handle auth, role-based access control, and SSO for enterprise buyers?

Accepted Answer

Better Auth is our default — it is open-source, runs on your infrastructure, and gives you full control over the session model, the token lifetimes, and the permission logic. We implement fine-grained RBAC on top of it: roles, permissions, resource-level policies, and an admin UI for managing team members and their access. Clerk is the right alternative when you want a managed auth service with a polished pre-built UI — useful for MVPs where time-to-ship is the constraint, or when your team does not want to own the auth infrastructure. For enterprise buyers, SAML 2.0 SSO is frequently a procurement requirement — a buyer using Okta or Azure AD will expect your product to appear in their identity provider and support just-in-time provisioning. We implement SAML SSO at the Production or Enterprise tier using the appropriate adapter for your auth layer. We also implement session management features that enterprise security teams ask for: session timeout, concurrent-session limits, IP allowlisting, and a full user-activity audit log.

Question 6

How do you add AI features to a SaaS product, and how does usage-based billing work for AI?

Accepted Answer

AI features in a SaaS product are not a bolt-on — they need to be designed into the UX and the data model from the start or they feel like a separate tool stapled onto the side. We integrate LLM features at the workflow level: semantic search embedded in the existing search UI, document summarisation triggered from the document viewer, a conversational agent that knows the user's account context. The model layer is provider-agnostic — OpenAI, Anthropic, or a self-hosted model — with a thin abstraction so switching providers does not require rewriting the feature. Usage-based billing means metering token consumption or operation counts at the user or team level, storing that usage in a Postgres table, syncing it to Stripe Billing metered records, and surfacing a usage dashboard to the customer. We also build eval pipelines: a structured set of test cases with expected outputs that run on every model or prompt change so you know before you ship whether the AI feature got better or worse. This is the difference between AI that ships once and AI that improves over time.

Question 7

How much does it cost to build a SaaS product with Vellumarc?

Accepted Answer

The honest answer is that cost is a function of scope, not of time. An MVP — auth, billing, one core workflow, admin dashboard, and a production deployment — runs $20k–$60k and ships in 8–12 weeks. The range reflects scope: a billing-only MVP with a simple workflow is at the lower end; a multi-role admin system with complex permissions and a data-import pipeline is at the upper end. A full production SaaS — multi-tenant, RBAC, integrations, observability, performance-budgeted, and retainer-included for 60 days post-launch — runs $60k–$200k over three to six months. Enterprise SaaS with SOC-2 posture, SAML SSO, enterprise SLAs, and white-glove onboarding runs $200k–$1M+ over six to twelve months. All quotes are fixed-scope, in USD, and itemised so you can see what each module costs and trim what you do not need in the first phase. We do not bill by the hour for project work; you know the number before we start.

Question 8

What ships in 8 weeks versus 12 weeks — and how do you keep scope from slipping?

Accepted Answer

An 8-week MVP assumes a tight, clearly defined scope agreed at kickoff: one auth method (email and password), one billing model (flat monthly subscription), one core workflow with no branching edge cases, and a simple admin view. A 12-week MVP typically includes OAuth providers, Stripe metered billing or a more complex plan structure, two or three related workflows, or a data-import flow from an existing tool. What consistently slips is scope that was not in the original brief — an additional user role discovered in week four, a new integration that surfaces during a demo, a design revision that requires reworking a data model. We prevent this with a locked scope document signed before sprint one, a weekly demo that surfaces misalignments early (week two is far cheaper to correct than week ten), and a public backlog where new requests queue rather than interrupt the current sprint. Additions are quoted, approved, and added to the following sprint — the MVP deadline does not move to accommodate them.

SaaS Development Company in India for Global Founders

What we build

B2B SaaS Platforms

Multi-Tenant Systems

Real-Time & Chat Apps

AI-Powered SaaS

Tech stack we use

How we work

Discovery

Architecture

MVP

Production

Scale

Pricing

SaaS MVP

Production SaaS

Enterprise SaaS

Frequently Asked Questions

Guides on SaaS Development

How Much Does a Website Cost in India in 2026? Honest Breakdown

Mobile App Development Cost in India: What You'll Actually Pay in 2026

Let’s build something your competitors can’t ignore.

Consultation

Development

Brand + UI/UX