Founders before launch
Tenancy, plans and billing settled before the first paying customer.
SaaS Consulting
SaaS consulting and SaaS product development
Turning software into a SaaS business means building things customers never see in a demo: tenancy, plans, billing, metering, onboarding and the admin tools your support team needs. Agnotic Technologies helps founders and product leaders decide each of these early and builds them into the product.
Tenancy modelPlans and entitlementsBilling and usage meteringSelf-serve onboarding
Trusted by global innovators
SaaS consulting
What does SaaS consulting cover?
SaaS consulting is helping a company design the product mechanics that turn software into a subscription business. Agnotic Technologies works with founders and product leaders on the tenancy model, plans and entitlements, subscription billing and usage metering, trials and self-serve onboarding, tenant administration and the controls a SOC 2 audit examines, then builds them.
These decisions are cheap on day one and expensive once customers depend on them. A plan check written straight into the code, or an invoice built from usage nobody can verify, takes months to unwind later.
Deep multi-tenant backend design, such as isolation tiers, data residency and customer-managed keys, is covered on our high-scale SaaS backend page. We build the controls your auditor will test; your SOC 2 report is about your company and your systems.
Decision table
Which SaaS architecture choices fit your product, and what do they cost to change?
Tenancy, pricing and entitlement choices side by side. Most products combine one choice from each group.
| Choice | When it fits | Cost to change later |
|---|---|---|
| Pooled tenancy: shared infrastructure and tables with a tenant ID | Many small and mid-size customers with similar needs | Medium: moving a large tenant out needs data export and routing work |
| Bridge tenancy: shared application, separate schema or database per tenant | A mix of customers, some asking for data separation | Medium: every schema change runs across every tenant database |
| Silo tenancy: a dedicated stack per tenant | A few large or regulated customers with strict isolation terms | High: each stack is patched and upgraded, so automation is needed from the start |
| Flat subscription pricing | One clear product with similar usage per customer | Low, if prices live in the billing system and not in code |
| Per-seat pricing | Value grows with the number of users | Low to medium: needs seat counting and proration |
| Usage-based pricing | Value tracks consumption, such as API calls, records or compute | High: needs a metering pipeline customers can trust before the first invoice |
| Entitlements in code | Very early, with one or two plans | High: every new plan or custom deal means code changes across the product |
| Entitlements in a service or table | Several plans, add-ons or custom deals | Low: sales and support change access without a release |
Two choices are hardest to undo: plan checks scattered through the code, and usage pricing launched before metering can be trusted.
What do we build into a SaaS product?
The SaaS mechanics that sit around your core features.
Plans and entitlements
One source for which tenant can use which feature and limit, checked by every service.
Subscription billing
Plans, trials, upgrades, downgrades, proration and invoices through your billing provider, with webhooks handled safely.
Usage metering
Usage events captured once, deduplicated, aggregated per tenant and reconciled before they reach an invoice.
Self-serve onboarding
Sign-up, email verification, workspace setup, sample data and first-run guidance.
Tenant admin
Customer admins manage users, roles, SSO settings and billing details without contacting support.
Support tooling
Internal tools to find a tenant, see its plan and usage and act on its behalf, with every action logged.
From one customer to many
How do you turn single-customer software into SaaS?
For companies whose software runs as a separate copy for each customer today.
Find the per-customer differences
List every fork, config file and custom feature that differs between customers today.
Introduce the tenant
Add a tenant ID to data, requests and logs, and route each request to its tenant's data.
Turn differences into configuration
Custom features become plan features or tenant settings, not code branches.
Add self-serve sign-up, billing and admin
New customers can sign up, choose a plan, pay and invite their team without an engineer.
Automate tenant operations
Provisioning, upgrades, backups and offboarding run per tenant from scripts, not by hand.
Who it is for
Who do we help build SaaS products?
Teams deciding how their software will be sold, billed and run for many customers.
Software vendors moving from installs to SaaS
Products that run as one copy per customer today.
Agencies turning a client build into a product
Custom software that other customers now want to buy.
SaaS companies adding usage pricing
Teams that need a metering pipeline customers will trust.
Products moving upmarket
Larger customers asking for tenant admin, stricter tenancy and audit evidence.
Failure points
Where do SaaS products get stuck?
Problems we are asked to fix in SaaS products after launch.
Challenge
A big customer asks for a feature, and it ships as a special case in the code.
Agnotic approach
Custom terms are modelled as entitlements or add-ons, so the code stays the same for everyone.
Challenge
Customers dispute usage invoices.
Agnotic approach
Customers see the same usage records the invoice is built from, event by event.
Challenge
Trials convert badly because setup needs a sales call.
Agnotic approach
The first useful result is reachable without help, and the time to reach it is measured from sign-up.
Challenge
Support staff use the production database to fix tenant problems.
Agnotic approach
Support tools give scoped, logged access, so nobody needs direct database access.
Challenge
One tenant's heavy job slows down every other tenant.
Agnotic approach
Per-tenant quotas and queues limit how much shared capacity one tenant can use.
Audit readiness
Which product controls will a SOC 2 auditor look for?
SOC 2 is an attestation about your company's controls. These are the product controls we build so the evidence exists.
- Role-based access for customer users and for your own staff
- SSO and multi-factor authentication for staff, with regular access reviews
- An audit log of admin, support and data access actions
- Change management: reviewed pull requests, CI checks and tracked deployments
- Encryption in transit and at rest, with keys managed in your cloud provider
- Backups, restore tests and tenant data deletion on request
Frameworks
Which frameworks and models guide our SaaS work?
References behind the tenancy, metering and control choices on this page.
NIST SP 800-145AWS SaaS LensSOC 2OAuth 2.0 and OpenID ConnectSCIM
Facts and sources
Facts behind SaaS product decisions
Definitions and guidance from NIST, AWS and the AICPA, each linked to its primary source.
NIST's definition of cloud computing lists measured service as an essential characteristic: resource use such as storage, processing, bandwidth and active user accounts is metered, monitored, controlled and reported to both provider and consumer.
Source: NIST SP 800-145, The NIST Definition of Cloud ComputingNIST defines software as a service as the consumer using the provider's applications on a cloud infrastructure without managing that infrastructure, with the possible exception of limited user-specific configuration settings.
Source: NIST SP 800-145, The NIST Definition of Cloud ComputingThe AWS SaaS Lens groups SaaS architectures into silo, bridge and pool models, and notes that even a silo with dedicated resources per tenant relies on shared identity, onboarding and operations, which separates SaaS from a managed service model.
Source: AWS Well-Architected SaaS Lens: silo, pool and bridge modelsA SOC 2 report covers an examination of controls at a service organization relevant to security, availability, processing integrity, confidentiality or privacy.
Source: AICPA & CIMA: SOC suite of services
Scope and cost
What drives the cost of SaaS product development?
There is no price list. These factors decide the size of the build, and we go through each one on the scoping call.
Starting point
A new product, or existing software that runs one copy per customer today.
Tenancy model
Pooled is simplest to run; bridge and silo options add routing and automation.
Pricing model
Flat and per-seat pricing need less than usage-based pricing and its metering pipeline.
Integrations
Billing provider, CRM, identity providers and analytics.
Compliance scope
The controls and evidence your customers and auditors expect.
Admin and support tooling
How much customers and your support team must be able to do without engineers.
Frequently Asked Questions
We do not publish prices. A short decision engagement is fixed work; building the SaaS mechanics depends on your starting point, tenancy and pricing models, integrations and compliance scope. You get a written proposal after the scoping call.
Most products start pooled, because it is cheapest to run and operate. Add bridge or silo options when specific customers need them, and design tenant routing early so that move stays possible.
Yes. We connect your product to a billing provider, model your plans as entitlements, handle payment and failure webhooks, and move existing customers onto plans.
We help with how pricing works in the software: which models it supports and what each needs to run. The price itself is your decision, and we do not give pricing advice with numbers.
A SOC 2 report comes from an independent CPA firm and covers your organization's controls. We build the product and engineering controls an auditor tests and keep the evidence, but the report itself comes from your audit.
SaaS consulting for startups is most useful before launch, when tenancy, entitlements and billing can be designed in cheaply. A short engagement settles those choices and sets up the first plans.