How to choose a SaaS development company

Short answer: choose the team that can show, not just say, that it has built the three things that separate SaaS from other web software: multi-tenant data isolation, subscription billing tied to entitlements, and roles and permissions enforced on the server. Ask for a walkthrough of each. Put every account that holds customer data or money in your company’s name. Agree how work continues after launch before the build starts. Then compare proposals line by line against the checklist at the end of this guide.

General due diligence (team, process, pricing models, IP, warranties) applies to any software vendor and is covered in our list of 27 questions to ask a development agency. If the project is a first release on a tight budget, the guide to choosing an MVP development company explains scoping discipline and paid discovery. This article adds only what is particular to SaaS.

Why a SaaS build needs a different evaluation

A marketing site or a single-company internal tool can be built well by a team that has never thought about tenants. A SaaS product cannot, for four reasons:

• Many customers share one system. A mistake in data scoping shows one customer another’s records. That is a breach, not a bug.
• Money moves on a schedule without anyone clicking. Renewals, failed cards, upgrades mid-cycle, refunds and tax all happen while nobody is watching, and errors reach customers as wrong invoices.
• Customers have their own internal structure. Owners, administrators, members, guests, and rules about who can see and do what. Larger customers will ask for single sign-on and audit logs.
• The product is operated, not delivered. Uptime, migrations with live data, support tooling and continuous releases are part of the job from the first paying customer.

A vendor who has been through these once makes different early decisions from one who has not, and early decisions in these areas are the expensive ones to reverse.

Evidence to ask for

Ask every shortlisted team for evidence in the three core areas, and in the two operational ones that sit around them. “Evidence” means something you can look at: a live product, a screen-share of a real system with sensitive details hidden, a diagram the team drew for a real project, or code.

If a team’s client work is under NDA, the mechanisms can still be described and drawn without naming anyone. Knowledge of this kind is hard to fake in a live conversation: ask a follow-up question and see whether the detail holds.

Architecture questions, and what good answers sound like

You do not need to be an engineer to use these. Ask them in a call with the person who would lead the build, not the salesperson, and listen for mechanisms and trade-offs. The background to most of them is in our guides to SaaS architecture and stack choices and multi-tenant isolation in practice.

1. Which tenancy model would you use for our product, and what would make you change it?

Good: a recommendation tied to your situation. Usually a shared database with a tenant ID on every row, with a stated condition under which a large customer could be moved to a dedicated database later. Weak: “a separate database for each customer, for security” with no mention of what that does to migrations and running cost, or no clear answer at all.

2. How do you make sure one customer can never see another’s data?

Good: scoping enforced in one place; optionally database row-level security underneath; the same scoping for files, caches, search and background jobs; automated tests that log in as one tenant and try to reach another’s records. Weak: “our developers are careful” or “we do code review”. Both are true of every team that has had a leak.

3. How does our application learn that a customer’s payment failed, and what happens next?

Good: the billing provider sends a webhook; the signature is verified; the handler is idempotent because events can arrive twice or out of order; the local subscription record is updated; the customer gets reminder emails and a grace period; access is restricted, not deleted, if payment is never recovered. Weak: “the payment provider handles that.” It handles the retry. It does not decide what your product does.

4. Where do plan limits live, and how would we change pricing next year?

Good: plans and limits are defined in one configuration; features ask a single entitlement function; existing customers can stay on an old plan; per-customer overrides are possible for negotiated deals. Weak: plan names checked in conditions scattered through the code, which turns every pricing change into a development project.

5. How are users, organisations and roles modelled?

Good: a person is one user who can belong to several organisations through memberships, each with its own role; invitations are their own object; the design leaves a path to single sign-on. Weak: each user belongs to exactly one company. It is the most common early modelling mistake and tedious to undo once there is live data.

6. How do you change the database schema once customers are using the system?

Good: versioned migrations run by the deployment pipeline; changes made in backward-compatible steps; large data updates run in batches in the background; tested on a copy of production-sized data. Weak: a maintenance window for every change, or manual edits on the production database.

7. What stops one heavy customer from slowing everyone down?

Good: rate limits per tenant, heavy work moved to background jobs with per-tenant concurrency caps, query timeouts, and metrics broken down by tenant so that the cause is visible. Weak: “we will scale the servers.” That raises your bill and does not protect the other customers.

8. How would our support staff help a customer who cannot see a record?

Good: an internal admin area with tenant search and time-limited impersonation that is written to an audit log and visible to the customer’s administrators if needed. Weak: a shared super-admin login, or developers looking in the database.

9. A customer cancels and asks for their data, then asks for it to be deleted. What happens?

Good: an export job that covers every table and file belonging to the tenant; deletion after a grace period, including files and search indexes; an honest statement about backups ageing out and invoices being retained for tax reasons. Weak: “we can write a script when that comes up.” It comes up in the first enterprise security questionnaire.

10. What will you buy instead of build?

Good: authentication, payments, email delivery, error tracking and file storage come from established services, registered in your name, with a reason for each choice and a note on how its price grows. Weak: a custom authentication or billing system, which adds risk and cost to the parts of the product no customer pays you for. Equally weak: a proprietary in-house platform that your product would depend on and that only this vendor can maintain.

Ownership of cloud and billing accounts

Code ownership is covered in any sensible contract. With SaaS, the accounts matter as much as the code, because they hold live customer data, payment methods and your sending reputation. Settle the following before work begins.

• Create the accounts yourself and invite the vendor. It takes an hour and removes a whole category of dispute.
• Keep the root credentials and two-factor devices with a founder, not with the vendor’s lead developer.
• Ask for infrastructure to be defined in code or documented step by step, so that someone else could rebuild it.
• Name the vendor as a sub-processor in your own data-protection paperwork if they can access customer data, and cover confidentiality and data handling in the contract. Our software development contract checklist lists the clauses to look for.

A vendor who proposes hosting your product in their own cloud account “to keep things simple” may mean well. The arrangement still leaves you unable to leave without their help, and it should be declined politely.

The post-launch iteration model

With most SaaS products the first release is a minority of the total engineering the product will ever receive. A vendor whose plan ends at launch is proposing a project, and you are building a business. Ask each team to describe, in writing:

• The engagement after launch: retainer, standing team or ad-hoc hours; the minimum commitment; how capacity can go up and down
• Incident response: who is alerted when production fails, during which hours, with what response time, and what happens outside those hours
• Routine upkeep: dependency and security updates, database maintenance, backup restore tests, cost reviews, and how often each happens
• Planning rhythm: how usage data, support tickets and sales feedback turn into the next month’s work
• Release practice: how often they ship, how changes are tested, how a bad release is rolled back
• Continuity: whether the engineers who built the product stay on it, and what happens if one leaves
• The exit: how they would hand over to an in-house team or another vendor, including documentation and a period of overlap

The right model changes over time. A fixed-scope first release followed by a monthly arrangement is common, and the trade-offs are compared in fixed price vs time and materials. What matters at selection time is that the vendor has a model, has priced it, and is comfortable describing the day you stop needing them.

Red flags specific to SaaS

• Tenancy is absent from the proposal. If the word does not appear, the team is quoting for a single-customer application and the difference will surface later as a change request.
• Billing appears as one line: “Stripe integration”. A real estimate separates checkout, webhooks, plan changes, failed-payment handling, invoices, tax settings and the customer portal.
• No internal admin tool in scope. You will be running the product blind from the first day.
• A proprietary “SaaS starter platform” you cannot leave. Reusable starting code is fine and saves money. Ask for its licence terms in writing and confirm you may keep and modify it indefinitely without the vendor.
• Microservices and a container-orchestration cluster for a product with no customers. The cost is yours and the benefit belongs to a company many times your size.
• Accounts in the vendor’s name, as described above.
• Compliance promises. “We will make you SOC 2 compliant” or “this will be HIPAA compliant” cannot be delivered by a development vendor alone. Those are organisational programmes with auditors. A vendor can build in a way that supports them and should say exactly that.
• No questions about your pricing. Pricing determines entitlements, metering and the data model. A team that does not ask has not thought about how the build connects to revenue.
• Staging and automated deployment described as “phase two”. They are how a live product is changed safely.
• A quote far below the others with the same feature list. Usually the list is the same and the hidden work is not. The cost blocks to compare are in our guide to SaaS development cost.

Proposal comparison checklist

Put the proposals side by side and mark each line as included, excluded or not mentioned. “Not mentioned” is the category that produces surprises, so send those lines back as questions.

Tenancy and data

• Tenancy model named, with where isolation is enforced
• Automated cross-tenant access tests
• Tenant data export and deletion

Identity

• Organisations, memberships, invitations, roles
• Authentication approach (managed service or library) and a path to single sign-on
• Server-side permission checks; audit log of significant actions

Billing

• Provider named; account in your company’s name
• Checkout, customer portal, upgrades and downgrades, cancellations
• Webhook handling and failed-payment flow
• Entitlements and plan limits; trials; tax approach stated or explicitly left to your accountant

Product

• Onboarding flow for a new organisation
• Transactional emails with an authenticated sending domain
• Internal admin tool with audited support access

Operations

• Staging and production environments; automated deployments
• Error tracking, logs, uptime alerts
• Backups with a tested restore
• Migration approach for live data

Commercial

• All accounts registered to you; code and IP assignment on payment
• Licence terms for any vendor-owned starter code
• Warranty period for defects
• Post-launch model priced; handover terms

A proposal that covers these lines at a higher price is frequently the cheaper one over two years. One that omits half of them is an estimate for a different product.

Where BBR stands

You should apply the same tests to us. BBR Studio Labs is an independent studio in Istanbul working remotely in English. Our publicly visible work is our own published products, described in the case studies, not a roster of named SaaS clients, and we will not pretend otherwise. What we can offer a careful buyer is what this guide recommends asking of anyone: direct answers to the ten questions above from the engineers who would do the work, a scoped roadmap with agreed acceptance criteria before the build, prototypes reviewed before full development, working increments you can try, source-code handover with documentation, and ownership and licences set out in the project contract. We also ask clients to register the cloud, billing and domain accounts themselves, for the reasons given above. Our default stack for this kind of product is TypeScript, React or Next.js, Node.js and PostgreSQL.

How we scope, price and run these projects is set out on the SaaS development page, and the working terms that apply to every engagement are on how we work.