Understanding the work
What does a SaaS software development company do?
A SaaS software development company builds software sold as a subscription service, where many customers (tenants) share one running product. Beyond features, it designs tenant isolation, sign-up and onboarding, identity and single sign-on, metering and billing, per-tenant monitoring, and the security controls that business buyers check before they sign.
Building SaaS is different from building a one-off application for one client, which is why a SaaS software development company needs product and operations skills as well as coding skills. You ship one product to many organizations, each with its own users, data, settings, and contract terms, and you carry the hosting bill. Our software development company guide covers engagement models and contracts in general; this page focuses on what is specific to subscription products.
Multi-tenancy is an architecture in which one deployment of a software product serves many customer organizations, called tenants, while keeping each tenant's data, configuration, and users separate.
What a SaaS partner builds beyond the product
- A control plane: tenant sign-up, provisioning, plan management, and an internal admin console.
- Identity: user management, roles, and enterprise single sign-on.
- Billing: plans, trials, metering, invoicing, and dunning for failed payments.
- Operations: deployment pipelines, monitoring by tenant, backups, and incident response.
Types of SaaS products
SaaS products differ mainly by buyer and scope. B2B SaaS sells to organizations and needs admin controls and enterprise features; B2C SaaS sells to individuals and depends on self-service and payments at scale. Vertical SaaS serves one industry, and many companies add a SaaS offering to an existing product or service.
| Type | Examples | What drives effort |
|---|---|---|
| B2B SaaS | Project tools, HR and finance software, developer platforms | Roles and permissions, SSO, audit logs, admin consoles, security reviews by buyers |
| B2C SaaS | Consumer subscriptions, personal productivity, learning apps | Self-service sign-up, payments and cancellation flows, app stores, support at volume |
| Vertical SaaS | Software for clinics, law firms, contractors, or property managers | Industry rules, integrations with sector systems, domain-specific workflows |
| Horizontal SaaS | Tools for one function across industries, such as scheduling or e-signature | Configurability, integrations marketplace, competition on usability |
| API-first and usage-based | Data, messaging, or AI services billed by usage | Metering accuracy, rate limiting, developer documentation, cost per request |
| SaaS added to an existing product | A hardware maker adding a cloud dashboard, or on-premises software moving to a hosted subscription | Migrating installed customers, licensing changes, retrofitting multi-tenancy |
Scroll the table sideways to see all columns.
Vertical SaaS inherits the rules of its industry. Clinical and insurance products, for example, carry obligations covered in our guides to healthcare software development and insurance software development.
Build or buy the parts of a SaaS platform
Most SaaS teams buy the commodity parts of the platform, such as payments, billing, authentication, email delivery, and observability, and build the features that make the product distinct. Building identity or billing from scratch rarely pays off early, but every bought component adds a running cost and a dependency to manage.
| Component | Usually | Why |
|---|---|---|
| Payments and billing | Buy | Payment security, invoicing, proration, and dunning are hard to get right |
| Authentication and SSO | Buy or use open source | Standards support (SAML, OpenID Connect, SCIM) and security fixes are ongoing work |
| Sales tax calculation | Buy | Rates and taxability rules change across many jurisdictions |
| Feature flags and observability | Buy or use open source | Mature tools exist; open standards such as OpenTelemetry reduce lock-in |
| Core product and data model | Build | This is what customers pay for |
| Tenant control plane | Build, often on a framework | It encodes your plans, limits, and onboarding steps |
Scroll the table sideways to see all columns.
Architecture and security
SaaS architecture: tenancy, identity, and billing
SaaS architecture starts with tenant isolation: whether each customer gets dedicated resources (silo), shares everything (pool), or a mix (bridge). Around that sit tenant onboarding, identity and SSO for enterprise customers, metering and billing, sales tax handling, feature flags, observability by tenant, and controls for noisy neighbors that consume shared capacity.
Tenant isolation models
Expect any experienced SaaS software development company to discuss these models early. The AWS SaaS Lens describes three of them, and Microsoft's Azure multitenant architecture guide covers the same tradeoffs in its own terms. Most products mix models by tier or by layer of the stack.
| Model | How it works | Strengths | Tradeoffs |
|---|---|---|---|
| Silo | Each tenant gets its own resources, such as a database or full stack | Strong isolation, easier data residency, simple per-tenant cost tracking | Higher cost per tenant, more deployments to manage, slower onboarding |
| Pool | Tenants share infrastructure; data is separated by tenant ID and access policies | Lowest cost per tenant, fast onboarding, one deployment | Isolation depends on code and policies; noisy neighbor risk; harder per-tenant cost data |
| Bridge | Some layers pooled, others siloed, or premium tenants siloed | Balances cost and isolation; supports enterprise tiers | More complexity in deployment and operations |
Scroll the table sideways to see all columns.
Architecture checklist
- Tenant context everywhere: every request, query, log line, and background job carries a tenant identifier, enforced in shared code or database policies rather than left to each developer.
- Identity and SSO: enterprise customers expect SAML 2.0 or OpenID Connect single sign-on, SCIM user provisioning, and roles they can manage themselves.
- Tenant onboarding: automated provisioning of the tenant, admin user, default settings, and plan limits, so sales does not wait on engineering.
- Metering and billing: record usage events reliably and reconcile them with invoices. Platforms such as Stripe Billing handle subscriptions, usage-based pricing, proration, and invoices, but you still define what to meter.
- Sales tax: whether SaaS is taxable varies by state, and states can require out-of-state sellers to collect once they pass economic nexus thresholds. The Streamlined Sales Tax project aims to simplify compliance across member states. This is general information, not tax advice; confirm with a tax advisor.
- Feature flags: release features by tenant or plan, run betas with selected customers, and turn off a faulty feature without a redeploy.
- Observability per tenant: metrics, traces, and logs tagged by tenant so support can see one customer's experience and finance can see cost by tenant.
- Noisy neighbors: rate limits, quotas, and workload queues so one heavy tenant cannot slow everyone else.
Our guide to cloud development services covers serverless, containers, and other hosting choices that sit underneath these patterns.
SaaS security and compliance requirements
Business buyers judge SaaS vendors through security reviews. Expect requests for a SOC 2 report, sometimes ISO/IEC 27001 certification, evidence of secure development such as OWASP ASVS testing, privacy terms that meet US state laws and GDPR where relevant, an accessibility conformance report, and answers on where data is stored.
| Requirement | What it involves | Build implication |
|---|---|---|
| SOC 2 | An independent auditor's report on controls under the AICPA Trust Services Criteria; Type 1 covers design at a point in time, Type 2 covers operation over a period | Access reviews, change management, logging, backups, and vendor management built into daily engineering |
| ISO/IEC 27001:2022 | A certified information security management system; the transition from the 2013 edition ended October 31, 2025 | Risk assessment, documented controls, internal audits |
| OWASP ASVS | A catalog of application security requirements at three levels; version 5.0 is current | Use it as the security acceptance criteria for features and penetration tests |
| Privacy laws | Many US states have comprehensive privacy laws; California's CPPA regulations on risk assessments and cybersecurity audits took effect January 1, 2026, with automated decisionmaking rules from January 1, 2027. EU customers bring GDPR obligations | Data processing agreements, data export and deletion by tenant, subprocessor lists |
| Accessibility | Enterprise and public sector buyers often ask for a VPAT, the template used to produce an accessibility conformance report against WCAG 2.2 and Section 508 | Accessible design and testing from the first release, not a retrofit |
| Data residency | Customers may require data stored or processed in specific regions | Regional deployments or siloed tenants; region-aware backups and support access |
Scroll the table sideways to see all columns.
SOC 2 readiness is easiest when your SaaS software development company builds the controls in early: single sign-on and MFA for staff, infrastructure as code, peer-reviewed changes, centralized logs, and documented incident response. Retrofitting them after a large customer asks for a report is slower and more disruptive. This is general information, not legal advice; confirm obligations with counsel.
How SaaS products are built and launched
SaaS delivery usually moves from product discovery and pricing decisions to a platform foundation (tenancy, identity, billing, pipelines), then a first release to design partners, a broader launch, and continuous delivery. Unlike a project, it never really ends: the product needs a team that keeps shipping, operating, and supporting it.
- Discovery and pricingTarget customers, core jobs, packaging, and the pricing metric, since what you charge for decides what you must meter.
- Platform foundationTenant model, identity, billing integration, environments, CI/CD, and observability.
- Design partner releaseA small group of customers uses the product under close support, behind feature flags.
- Security baselineControls and evidence for a SOC 2 readiness assessment, plus a penetration test.
- General availabilitySelf-service or sales-led onboarding, support processes, and status communication.
- Continuous improvementUsage analytics, frequent releases, and regular reviews of cost per tenant.
Ask a SaaS software development company which of these steps it will own and which your team will. If you are still testing whether customers want the product at all, start with our MVP software development guide before investing in a full SaaS platform.
Decisions
What drives SaaS development and running costs
SaaS cost has two parts: the build and the ongoing cost of running the service. Build cost is driven by product scope, platform features such as SSO and billing, integrations, and compliance work. Running cost is driven by the tenancy model, cloud usage per tenant, third-party services, support, and the team that keeps shipping.
| Driver | Why it matters |
|---|---|
| Tenancy model | Siloed tenants raise infrastructure and operations cost per customer; pooled tenants lower it but need more isolation engineering |
| Enterprise features | SSO, SCIM, audit logs, custom roles, and data residency add build and support effort |
| Integrations | Each connector to another product needs building, monitoring, and updating when that product's API changes |
| Cloud usage per tenant | Compute, storage, data transfer, and AI model calls scale with customer activity and shape gross margin |
| Third-party services | Billing, authentication, email, monitoring, and tax tools often charge by user, transaction, or revenue |
| Compliance | Audits, penetration tests, compliance tooling, and the staff time to produce evidence each year |
| Support and success | Onboarding help and support load grow with customer count and product complexity |
| Continuous development | A SaaS product needs an ongoing team; the first release is the start of spending, not the end |
Scroll the table sideways to see all columns.
This guide does not quote prices. Ask any SaaS software development company you consider to estimate running cost per tenant at a few customer counts, and to show which design choices change it.
Contracts and ownership in SaaS development
When a SaaS software development company builds your product, the contract should assign the code and IP to you, keep cloud, billing, and code accounts in your name, define how customer data is handled, and set out support and handover terms. You also need your own customer-facing terms, such as a subscription agreement, DPA, and SLA.
- IP assignment: custom code, designs, and documentation assigned to your company, with any reused components licensed to you on clear terms.
- Accounts: cloud, code hosting, payment and billing platforms, domains, and app store accounts registered to your company.
- Data: the developer acts as your service provider or subprocessor, with access limited and logged.
- Operations: who is on call, response times, and who pays for incidents caused by defects.
- Handover: documentation, runbooks, and knowledge transfer so an in-house team can take over.
The pillar guide's contracts section covers statements of work, acceptance, and warranty. This is general information, not legal advice; have counsel review your agreements.
How to choose a SaaS software development company
Choose a SaaS software development company by checking that it has built and operated multi-tenant products, can explain isolation and billing tradeoffs clearly, builds in security controls that support SOC 2, thinks about running cost per tenant, and will hand over a product your own team can run.
Evaluation criteria
- SaaS track recordMulti-tenant products in production, not only single-client applications, with references you can call.
- Architecture judgmentA reasoned recommendation on silo, pool, or bridge for your customers, tiers, and residency needs.
- Billing and identity experiencePast integrations with billing platforms and enterprise SSO, including edge cases such as plan changes and deprovisioning.
- Security practiceSecure development aligned with OWASP ASVS and the NIST SSDF, and experience supporting clients through SOC 2 audits.
- OperationsMonitoring, incident response, and on-call arrangements, or a clear plan for your team to own them.
- Product thinkingThey ask about pricing, onboarding, and churn, not just features.
Questions to ask a SaaS software development company
- How do you enforce tenant isolation in code and in the database, and how do you test it?
- How would our cost per tenant change between a pooled and a siloed design?
- Which SOC 2 controls will your engineering process produce evidence for?
- How do you meter usage, and how do you reconcile usage with invoices?
- What will our team need to run this product without you?
Red flags
- No answer on tenant isolation beyond "we filter by customer ID."
- Plans to build billing or authentication from scratch with no clear reason.
- Payment, cloud, or app store accounts set up in the developer's name.
- No discussion of running cost, only build cost.
- Security treated as a pre-launch penetration test rather than part of daily work.
If the SaaS product is mainly a web and mobile experience, our guide to cloud app development services covers app store releases and mobile backends. Organizations building internal platforms should see our enterprise software development guide.
Reference
SaaS software development company FAQs
What does a SaaS software development company do?
It designs and builds subscription software that many customers share, including the product features and the platform around them: tenant isolation, onboarding, identity and single sign-on, metering and billing, monitoring, and the security controls business buyers expect.
What is the difference between silo, pool, and bridge tenancy?
In a silo model each tenant gets dedicated resources. In a pool model tenants share infrastructure and are separated by tenant identifiers and access policies. A bridge model mixes the two, for example pooling the application layer while giving premium tenants their own databases.
Do we need SOC 2 before launching?
Not always. Many products launch first and pursue SOC 2 when business customers start asking for it. Building the controls into engineering from the start makes the audit faster when that time comes, and lets you answer security questionnaires credibly earlier.
Is SaaS subject to sales tax?
It depends on the state. Some states tax SaaS, others do not, and definitions differ. Out-of-state sellers may have to collect tax once they pass a state's economic nexus thresholds. Confirm your obligations with a tax advisor before you start invoicing.
Why do enterprise buyers ask for a VPAT?
A VPAT is a template for documenting how a product conforms to accessibility standards such as WCAG and Section 508. The completed document, an accessibility conformance report, helps buyers meet their own accessibility obligations and is common in procurement reviews.
Should we build our own billing system?
Usually not at first. Billing platforms handle subscriptions, proration, invoices, and failed payment recovery. Build your own metering logic and pricing rules, and reconsider a custom billing system only if your pricing model becomes something no platform supports.
Sources
- AWS, SaaS Lens: AWS Well-Architected Framework
- AWS, Silo, pool, and bridge models
- Microsoft, Architect multitenant solutions on Azure
- Stripe, Stripe Billing documentation
- Streamlined Sales Tax Governing Board, Streamlined Sales Tax
- AICPA and CIMA, System and Organization Controls: SOC suite of services
- ISO, ISO/IEC 27001:2022 Information security management systems
- OWASP, Application Security Verification Standard
- NIST, SP 800-218: Secure Software Development Framework (SSDF) Version 1.1
- IAPP, US State Privacy Legislation Tracker
- California Privacy Protection Agency, Announcement on approved regulations (September 2025)
- Information Technology Industry Council, Voluntary Product Accessibility Template (VPAT)
- GSA Section508.gov, Accessibility Conformance Reports
- W3C, Web Content Accessibility Guidelines 2.2
- OpenTelemetry, OpenTelemetry documentation
- IETF, RFC 7644: System for Cross-domain Identity Management (SCIM) Protocol
About this guide
This guide is published by Crecso as an independent educational resource and is part of our software development guide. It names platforms, standards, and regulations as examples only, is not affiliated with any software vendor or development firm, and does not describe services offered by Crecso. It is not legal, tax, or regulatory advice.
Last reviewed on . If you spot something that has changed, please let us know through our contact page.