SaaS · Multi-tenant · Subscriptions

SaaS development
from first tenant to paying customers.

We design and build subscription software: the product your customers log in to, and the parts they never see that make it a business. Tenancy, billing, permissions, onboarding, an admin back office and the metrics to run it, delivered by one team on a stack you can hire for.

Discuss your SaaS product ↗

What a SaaS build covers

The product,
and the business machinery around it.

A SaaS product is a web application that many customer organisations share, pay for on a recurring basis, and expect to be available every day. The core feature is usually less than half of the work. The rest is what turns a feature into something you can sell, support and measure.

Core product and tenancy

The workflow your customers pay for, built on a data model where every record belongs to a tenant (an organisation, workspace or account) and every query is scoped to it. Tenant isolation is tested, not assumed.

Accounts, roles and onboarding

Sign-up, email verification, team invitations, roles and permissions, and a first-run experience that takes a new user to the first useful result quickly. Single sign-on where enterprise buyers require it.

Subscription billing

Plans, trials, upgrades and downgrades, seat or usage-based pricing, invoices, failed-payment handling and a self-service billing portal, integrated with a hosted billing provider. Plan limits are enforced in the product.

Back office and metrics

An internal admin area to find a customer, see their plan and usage, fix data and support them safely. Product analytics and a basic revenue view so you can see activation, retention and churn from the first week.

Who this is for

Teams selling software on subscription.

SaaS development with BBR fits four situations:

Founders building a B2B SaaS product who know the customer and the problem well, often from years inside the industry, and need a team to build the first sellable version.
Agencies, consultancies and service businesses turning a repeatable service or an internal tool into a product that customers can use on their own.
Startups with a working prototype, often built with no-code tools or by a single developer, that now needs real tenancy, billing and permissions before more customers arrive.
Software companies adding a new product where the in-house team is fully committed to the existing one.

If what you need is a first release to test demand, the engagement follows our MVP development process with the SaaS building blocks included. If the software is for your own staff rather than for paying customers, custom software development or an internal tool is the closer match.

Products we can build

Vertical B2B tools: scheduling, quoting, inventory, compliance tracking, field operations, client portals
Workflow and collaboration products with teams, comments, files and notifications
Data and reporting products that ingest customer data and return dashboards, alerts or exports
API-first products with keys, usage metering and developer documentation
AI-assisted SaaS built on hosted language models, with per-tenant data boundaries and usage-aware pricing
A companion mobile app for the part of the workflow that happens away from a desk

The process

Decide the expensive things first.

A few SaaS decisions are hard to reverse: the tenancy model, how identity works and how billing maps to the product. We settle those in writing before the build, then deliver in increments you can log in to.

How we work in detail ↗

Discovery · 1–3 weeks

Users, buyer, pricing model, plans and limits, roles, integrations and data sensitivity. Output: prioritised feature list, a written scope with acceptance criteria, an architecture note covering tenancy, auth and billing, and a fixed quote.

Design · 2–4 weeks

Flows and interface design for sign-up, onboarding, the core workflow, team management and billing screens. Reviewed as a clickable prototype before engineering starts.

Build · 8–18 weeks

Short iterations on a staging environment. The tenant model, authentication and permissions come first because everything else sits on them. Billing is integrated in the provider’s test mode early, not in the final week.

Launch · 1–2 weeks

Production setup in your accounts, monitoring, backups with a tested restore, transactional email deliverability, live billing, and handover of code and documentation. Often a private beta with a handful of customers before public sign-up opens.

Iteration · monthly

After launch the work follows what customers do and ask for. This is scoped separately as a monthly plan under our product engineering model, or handed to your own team.

Technology approach

A monolith you can hire for.

Most SaaS products are best served by one well-structured application, one relational database and a small set of managed services. That setup is quick to build, cheap to run and familiar to almost any engineer you hire later.

Concern	Typical choice	Why
Web application	React / Next.js, TypeScript	One language across the stack, large hiring pool, fast marketing pages and app in one framework if wanted
Backend and API	Node.js, TypeScript	Shared types with the front end, mature ecosystem for billing, queues and integrations
Database	PostgreSQL, shared schema with a tenant ID	Simple to operate; row-level security available as a second line of defence
Authentication	Managed auth service or a well-maintained library	Password reset, MFA and SSO are solved problems; mistakes here are costly
Billing	Hosted subscription provider (e.g. Stripe)	Invoices, proration, retries, tax tooling and a customer portal without building them
Background jobs	Queue backed by PostgreSQL or Redis	Imports, exports, emails, webhooks and scheduled work kept off the request path
Email	Transactional email provider	Deliverability is a specialism; domain authentication set up properly
Observability	Error tracking, structured logs, uptime checks	You hear about a failure before the customer writes in
Hosting	Docker on a managed platform or cloud VM, in your account	Portable, predictable cost, you hold the keys

The list follows the product, not the other way round. A data-heavy product, strict data residency or an existing engineering team can each change it. The trade-offs, including when schema-per-tenant or database-per-tenant is justified, are covered in our SaaS architecture and stack guide.

Pricing factors

What moves the cost of a SaaS build.

Two products with the same one-line description can differ in cost several times over. The drivers are specific:

Billing model. Flat monthly plans are the cheapest to build. Per-seat pricing adds seat management and proration. Usage-based pricing adds metering, reporting and reconciliation.
Permission depth. Owner, admin and member is a few days. Custom roles, per-object permissions or approval chains are weeks, and they touch every screen.
Integrations. Each connection to a customer’s other systems (accounting, CRM, calendar, identity provider) has its own authentication, rate limits and failure modes.
Onboarding and data import. Importing a customer’s existing spreadsheet or legacy export is often what decides whether they activate, and messy data makes it slow to build well.
Enterprise requirements. SSO, audit logs, data export, configurable retention and security questionnaires arrive with larger buyers.
Core workflow complexity. Still the widest range of all. A scheduling engine or a rules-driven calculation is a different order of work from forms and lists.
Platforms. A responsive web app first; a native mobile companion adds a second front end.

We quote a fixed price against a written scope, with payments tied to milestones, and price any change before doing it. For effort figures per building block and three worked examples, see what it costs to build a SaaS product.

Common mistakes

Where SaaS builds go wrong.

Bolting tenancy on later

A product built for one customer and then “made multi-tenant” means revisiting every table, query, file path, cache key and background job. Scoping data to a tenant from the first migration costs almost nothing. Retrofitting it is one of the more expensive rewrites in SaaS, and the place where data leaks between customers come from.

Building your own billing

Subscription billing looks like a monthly charge and turns out to be proration, mid-cycle plan changes, failed cards, refunds, tax, invoices and disputes. Hosted providers have solved these. Build the mapping between their objects and your plans, and nothing more.

Pricing decided after the build

Whether you charge per seat, per workspace or per unit of usage changes the data model, the limits the product enforces and the onboarding flow. A rough pricing hypothesis belongs in discovery, even if the numbers change later.

No back office

Without an admin area, every support request becomes a developer running a database query in production. A plain internal panel to look up a customer, see their state and correct it pays for itself within weeks of launch.

Treating onboarding as polish

In B2B SaaS, a trial user who does not reach a useful result in the first session rarely returns. The path from sign-up to first value deserves the same design attention as the core feature.

Microservices for a product with no customers

Splitting a new product into services multiplies deployment, monitoring and debugging work for a team of two or three. Start with a modular monolith and extract a service when a measured problem demands it.

Fit

When BBR is the right team,
and when it is not.

We are a small, senior, independent studio in Istanbul working remotely in English. That shape suits some SaaS projects well and others poorly.

Good fit

We are likely a strong match if

You are building a B2B or prosumer SaaS product and want one team for design, backend, front end and release
You can describe the customer, the problem and roughly how you expect to charge
You want a fixed scope and price for the first release, then monthly iteration
You want cloud, billing and domain accounts in your company’s name from the start
You are comfortable with written updates, a staging link and scheduled calls

Not a fit

We will probably point you elsewhere if

You need a vendor that itself holds SOC 2, ISO 27001 or HIPAA attestations
You need a large team immediately, or staff on-site
The product is mainly a machine-learning research problem rather than a software product
You are looking for equity-only or revenue-share development
The idea has not been discussed with a single potential customer yet; interviews and a landing page come first

Why outsource a SaaS build

The first version needs a whole team, briefly.

Shipping a SaaS product takes product thinking, interface design, backend and database work, front-end engineering, billing integration and deployment. Few early-stage companies can hire all of that at once, and fewer can keep those people fully used once the first release is out. A studio gives you the complete set of skills for the months you need them, under a fixed price, with the code and accounts in your name.

It is not the right answer for everyone. If software is your long-term advantage you will want in-house engineers eventually, and a good partner plans for that handover: conventional technology, documentation, and no dependence on proprietary tooling. We set out the trade-offs in in-house vs outsourced development, and the practical mechanics of contracts, IP and milestones in how outsourcing an app or SaaS build works.

BBR builds and operates its own published products as well as client work, so we deal with releases, billing integrations and live users ourselves. The case studies describe the engineering decisions behind them.

Questions

Frequently asked
questions.

How long does it take to build a SaaS MVP?

A focused B2B SaaS first release usually needs 8 to 18 weeks of build time after discovery and design. The short end is a single core workflow with standard subscription billing and two roles. The long end has several integrations, usage-based billing or enterprise requirements such as single sign-on. Our guide on how to build a SaaS product breaks the timeline down by stage.

How much does it cost to build a SaaS product?

It depends on the number of SaaS building blocks the first release needs: tenancy, billing model, roles, onboarding, integrations and admin tooling, plus the core workflow itself. We quote a fixed price against a written scope. The SaaS development cost guide shows how to estimate a range yourself from effort and rates.

Do we need multi-tenancy from day one?

If you will sell to more than one organisation, yes, in the simple form: every record belongs to a tenant and every query is scoped to it. That decision is cheap at the start and expensive to retrofit. What you do not need on day one is a separate database per customer or per-tenant infrastructure. We compare the models in our SaaS tech stack guide.

Which billing provider do you use?

For most SaaS products we integrate a hosted subscription billing provider such as Stripe, because it handles cards, invoices, proration, failed-payment retries and a customer billing portal. If you sell in a way that needs a merchant of record for sales tax and VAT, we discuss providers that take on that role. We do not build card handling from scratch.

Who owns the code and the customer data?

You do. Ownership of the code and deliverables transfers to you under the project contract, the repository is handed over with documentation, and the product runs in cloud, billing and email accounts registered to your company. The details are on our how we work page.

Can you take over or extend an existing SaaS codebase?

Yes. We start with a paid review of the code, infrastructure and deployment process, then tell you plainly what we would keep, what is risky and what it would cost to continue. Ongoing work after that fits our product engineering model.

Can you build SOC 2 or HIPAA compliant software?

We can build with the engineering practices those frameworks expect, such as access control, audit logs, encryption in transit and at rest, and least-privilege infrastructure. BBR does not hold those certifications itself, and compliance is an organisational programme that your company owns. If certification is a launch requirement, say so at the start because it changes the scope.

Your next move

Planning a SaaS product?
Let’s scope the first release.

Tell us who the customer is, what they will pay for and what you have so far. We reply with questions, a suggested first-release scope and a realistic range.