Short answer
Judge a custom SaaS software development company on how it answers architecture questions, not on its portfolio. Ask how it will isolate tenant data, how billing edge cases are handled, what it is deliberately not building in v1, and who owns the cloud accounts. A firm that has shipped real SaaS answers those in specifics within minutes; one that hasn't answers in adjectives. Budget 6-12 weeks for a validation MVP and 4-8 months for a production v1, and insist on a phased estimate rather than a single fixed price quoted before discovery.
Most people evaluating a SaaS development partner ask to see the portfolio.
It's the wrong first move. Portfolios are curated, screenshots look identical across every agency, and a beautiful dashboard tells you nothing about whether the thing underneath can survive its fiftieth customer.
I've watched two products with near-identical front ends go in opposite directions. One scaled to a few hundred paying accounts without drama. The other hit about twelve customers and stalled, because every new client needed a developer to manually provision their account, and nobody had built a way to do that in under an hour.
The difference wasn't visible in either portfolio. It was in decisions made in week two.
So here are the questions that separate the firms who have shipped SaaS from the firms who have shipped websites and would like to try SaaS.
First, understand what usually kills these projects
CB Insights analysed 431 venture-backed companies that shut down since 2023. Running out of capital was cited by 70% but their own analysis calls that the ending, not the cause. The real reasons below: poor product market fit at 43%, bad timing at 29%, and unsustainable unit economics at 19% (CB Insights).
Read that list again, because none of those are engineering failures.
Which means the single most valuable thing a development partner can do for you is help you build less, faster, and get it in front of real users before the money runs out. A firm that enthusiastically agrees to your entire feature list is not being helpful. It's paid by the hour.
The right partner argues with your scope. Politely, but they argue.
What “custom SaaS” involves that ordinary app development doesn't
This is the part that gets underestimated, and it's where budgets quietly double.
A normal web application has users. A SaaS product has tenants organisations, each containing users, each with its own data, settings, branding, permissions and billing relationship. That single distinction pulls in an entire second product that never appears in the mockups:
•Tenant provisioning. A new customer signs up. What happens? If the answer involves a developer running a script, you don't have SaaS. You have hosted software.
•Subscription billing. Not “connect Stripe.” Proration when someone upgrades mid-cycle. Failed payment retry. Dunning emails. Grace periods. Downgrades that strip access to data the customer still owns. Annual versus monthly. Taxes across regions.
•The admin console. Your own team needs to see accounts, impersonate a user to debug a support ticket, extend a trial, issue a refund, suspend an account. This is roughly 20% of the build and appears in almost no initial estimate.
•Onboarding and empty states. The first ten minutes decide whether a trial converts. Most builds treat this as polish and run out of budget before reaching it.
•Observability. When one customer reports slowness, can you tell whether it's them, their data volume, or everyone?
When you compare two quotes and one is 40% cheaper, this list is usually the difference. Ask both firms to price these explicitly.
The seven questions
1. How will you isolate tenant data?
The most important technical question you will ask, and the fastest way to identify who has done this before.
There are three legitimate answers separate databases per tenant, separate schemas, or shared tables with a tenant ID on every row and each carries real trade-offs. OWASP's Multi-Tenant Security Cheat Sheet lays them out alongside the failure modes: cross-tenant data leakage, tenant impersonation, IDOR through manipulated IDs, and privilege escalation via admin functions (OWASP).
What a good answer sounds like: shared tables with row-level security enforced at the database layer, tenant ownership validated at the data access layer rather than only at the API endpoint, composite keys, and never trusting a tenant ID supplied by the client.
What a bad answer sounds like: “we'll add a company_id column and filter on it.” That works until one developer forgets one WHERE clause, and then a customer sees another customer's records. This is not hypothetical. It's the single most common serious bug in hand-rolled multi-tenant systems.
If you're in healthcare, finance or handling EU personal data, ask specifically whether separate schemas or databases are warranted for your enterprise tier.
2. What happens when a customer asks for their own subdomain, SSO, or a custom field?
Because they will, usually the first customer big enough to matter.
Custom domains, SAML or OAuth single sign-on, tenant-level feature flags, and per-tenant custom fields are all straightforward if the architecture anticipated them and expensive retrofits if it didn't. You don't need them in v1. You need the architecture to not preclude them.
Ask what it would cost to add SSO in month nine. A firm that has been there will give you a number and a reason. A firm that hasn't will say “that's easy.”
3. Who owns the code, the repository, and the cloud accounts?
Ask this early and get it in writing.
The cloud accounts matter more than the code. If the AWS or Digital Ocean account is in the agency's name with their card attached, you don't control your own product and migrating later is a project in itself. The correct arrangement: your organisation, your billing, developers added as users.
Same for the domain, DNS, app store accounts, Stripe, and the repository. Sensible firms set this up as a matter of course and will tell you so without being pushed.
4. What are we deliberately not building in v1?
This is my favourite question, because the answer reveals whether you're talking to a partner or a vendor.
A partner will have opinions. They'll tell you the reporting module can wait, the mobile app should be a responsive web view for now, and the integration you're excited about should follow your first ten customers rather than precede them. They may tell you a feature you're attached to shouldn't exist.
A vendor will say “we can build all of it.” That's not accommodation. That's a firm optimising for contract value while you optimise for survival and per the CB Insights data above, survival is the harder problem.
5. How do you handle billing edge cases?
Say the words “proration” and “dunning” and watch what happens.
If you get a confident, specific answer how mid-cycle upgrades are calculated, what the failed-payment retry schedule looks like, whether they'd use Stripe Billing versus building the subscription logic in-house and why that's a team that has run a live SaaS product and dealt with the support tickets.
If you get a vague answer about integrating a payment gateway, budget for a rebuild of your billing layer around month six. Billing bugs are uniquely damaging: they cost you money directly and destroy trust at the same time.
6. What does the back-office side look like?
Ask to see the admin panel from a past project, not the customer-facing dashboard.
Every functioning SaaS business needs internal tooling: account search, user impersonation for support, trial extensions, manual invoice adjustments, usage visibility, suspension. If a firm has never built this, their estimates are missing a meaningful chunk of work, and your operations team will spend the first year emailing developers to change things in the database.
7. What happens after launch?
Not “do you offer support” everyone says yes. Ask what specifically.
Who is on call if the platform goes down at 2am? What's the response time, in writing? How are dependency updates and security patches handled? What does month thirteen cost? Is there a handover package if you take development in-house later, and what's in it?
A firm that has supported live products answers this crisply because they've priced it. A firm that hasn't will improvise.
What it costs and how long it takes
Honest ranges from work we've delivered and seen quoted. Treat any number outside these bands as a signal to ask more questions, in either direction.
| SCOPE | TYPICAL TIMELINE | WHAT YOU GET |
|---|---|---|
| Validation MVP | 6–12 weeks | One core workflow, single tenancy or basic multi-tenancy, manual onboarding, Stripe Checkout |
| Production v1 | 4–8 months | Proper tenant isolation, self-serve signup, subscription billing, admin console, onboarding flow |
| Scale-ready platform | 8–14 months | The above plus SSO, public API, integrations, advanced roles, tenant-level analytics |
The variables that move a SaaS estimate most are not screen count. They are: number of third-party integrations, whether you need SSO and enterprise compliance early, how complex the permission model is, and whether the data model is genuinely novel or a recognisable shape.
A suspiciously cheap fixed price usually means the admin console, onboarding and billing edge cases have been quietly excluded. They'll return as change requests.
Red flags
•A fixed quote before any discovery. Nobody can price a SaaS build responsibly from a one-page brief. That number will be revised; the only question is who pays.
•No pushback on scope. See question four.
•The demo is all front end. Ask about the database, the deployment pipeline, the admin side.
•Cloud accounts in their name. Non-negotiable.
•Reluctance to start small. Any firm confident in its work should be happy to prove it on a paid discovery phase or a first module before you commit to the full budget.
What good looks like in the first two weeks
Before any code, you should have: a data model you can read, a decision on the tenancy approach with the reasoning written down, a scoped v1 with an explicit “not now” list, a clickable prototype of the two or three screens that matter, and a phased estimate.
If you get all of that from a paid discovery engagement, you've learned enough to judge the partner and if you walk away, you still own the artefacts. That's a fair deal in both directions.
What this looked like on a real project
A staffing company came to us running their entire operation on Excel client records, staff assignments, payroll, compliance documents, all in spreadsheets passed between people.
We built it as a multi-tenant SaaS platform rather than a single-company internal tool, which was the key early decision. That meant client and staff management, automated payroll with Indian statutory deductions handled correctly (GST, ESI, EPF), and compliance document tracking with expiry alerts but built so a second, third and tenth organisation could be onboarded without engineering work.
Around ten companies now run on it.
The payroll calculation logic was the hard part, not the interface. Statutory deductions have edge cases that only surface with real employee data, which is why we ran parallel calculations against their existing spreadsheets for a full cycle before anyone trusted it. That kind of verification rarely appears in a proposal. It should.
Frequently asked questions
What does a custom SaaS software development company actually do?
It designs and builds a subscription software product you own covering multi-tenant architecture, subscription billing, self-serve onboarding, the internal admin console, cloud infrastructure and post-launch support. It differs from general web development in that the product must serve many separate customer organisations from one codebase, securely and without manual setup.
How much does it cost to build a custom SaaS product?
A validation MVP typically runs 6–12 weeks. A production-ready v1 with proper tenant isolation, billing and an admin console generally takes 4–8 months. Cost tracks the timeline, the number of integrations and whether enterprise features like SSO are needed at launch rather than later.
Should we build an MVP first or go straight to a full product?
Build the MVP first in almost every case. With product-market fit cited in 43% of startup failures, the priority is putting something in front of paying users quickly and cheaply enough that you can afford to be wrong once.
What is multi-tenant architecture and do we need it?
Multi-tenancy lets one deployment serve many customer organisations with their data kept separate. You need it if you plan to sell to more than one organisation. Retrofitting it later is one of the most expensive changes you can make to a SaaS codebase.
Who owns the code and the intellectual property?
You should, in full, with the repository and cloud accounts in your organisation's name from day one. Get it in the contract before work starts.
Can we hire a development company to take over an existing SaaS product?
Yes, and it's common. Expect a two-to-three-week code audit first covering architecture, security, test coverage and dependency health, followed by a stabilisation phase before new features. Be sceptical of any firm that offers to take over an unfamiliar codebase without auditing it.
The bottom line
The firms worth hiring are the ones that make the project smaller and ask harder questions than you expected. The ones to avoid are agreeable, fast to quote, and vague about anything behind the screens.
If you're evaluating a custom SaaS software development company right now, take the seven questions above into your next call and note which answers arrive as specifics and which arrive as reassurance. It's a reliable filter, and it costs you nothing.
| Get a free SaaS consultation → |
|---|
Fly IT Solution builds custom SaaS products and multi-tenant platforms from Mohali, India and Minneapolis, USA, with more than a decade of delivery across healthcare, e-commerce, EdTech, staffing and logistics. Our stack for SaaS work is typically Node.js, React and PostgreSQL with multi-tenant architecture and subscription billing. The guidance above comes from projects we've shipped and supported including the parts that were harder than we estimated.
Sources: CB Insights, “The Top Reasons Startups Fail” (analysis of 431 shutdowns since 2023); OWASP Multi-Tenant Security Cheat Sheet (Open Worldwide Application Security Project).
