SaaS development built to survive its first hundred customers
A SaaS product is not one application with a login screen. It is a tenancy model, a billing system, an onboarding path and an operations burden, and the decisions you make about those in month one are the ones that hurt in year two.
What is SaaS development?
SaaS Development is building a software product that many separate customers use from one hosted codebase, with tenant isolation, self-service signup, subscription billing, entitlements and usage analytics. It suits Australian founders and established businesses productising something they already do well, and it differs from custom software because you sell it repeatedly.
Get a fixed written quote- Typical timeline
- 20 to 40 weeks to a commercially usable product
- What drives cost
- Depends on the tenancy model, how much of the billing and entitlement logic you need at launch.
- Best for
- Productising a repeatable service, or a vertical tool for an industry you know well
- You own
- The product, the codebase, the customer data and every vendor account
- Built with
- Multi-tenant data isolation, subscription billing, usage metering, tenant analytics
Your handover
Billing and entitlements are product features, not a plugin
Almost every SaaS team underestimates billing. Taking a card is the easy part and a payment provider handles it. The hard part is entitlements: what does this tenant have access to right now, what happens when they upgrade mid cycle, how is a proration handled, what does a failed card do to their access on day three versus day fourteen, and how does an annual plan interact with a seat count that changed in March.
- 01Tenancy and isolation model documented and implemented
- 02Authentication, roles, invitations and tenant administration
- 03Subscription billing with trials, proration and dunning
- 04Entitlement service governing plan based access
- 05Usage metering with defensible counters
- 06Self-service onboarding and behaviour driven email sequences
- Per tenant usage, activation and retention analytics
- Cost per tenant model with tagged infrastructure
- Security overview and completed vendor questionnaire template
Usage metering is designed alongside it
We build entitlements as a first class part of the domain rather than conditional checks scattered through the code. One place answers the question of what a tenant can do, the billing provider stays the source of truth for money, and a webhook pipeline keeps the two aligned with retries and reconciliation, because webhooks get missed. Usage metering is designed alongside it. If you intend to charge per record, per seat or per message, the counter must be accurate and defensible when a customer disputes an invoice. We also build the unglamorous parts early: GST handling for Australian customers, compliant tax invoices, dunning emails that recover revenue without insulting a good customer, and a self-service plan change that does not require a support ticket.
Automating a process you have not run yet is a reliable way to build the wrong thing twice.
Cloud cost per tenant decides whether your pricing works
Margins in SaaS development are made or destroyed in architecture. If a customer paying a modest monthly fee triggers a background job that scans their entire dataset every hour, you have built a business that loses more money as it grows. We model cost per tenant during design, not after the first alarming invoice, and we tag infrastructure so the number can be read from the console rather than estimated.
The usual offenders are predictable
The usual offenders are predictable. Per tenant background jobs that should be batched. Files stored in expensive tiers forever because nobody defined a lifecycle. Logs retained at full fidelity for a year. Data transfer between availability zones nobody noticed. A database sized for a launch spike that never scaled back down. We build with usage tiers in mind so heavy tenants can be identified and either priced correctly or moved to their own resources, and we run the hosting on the principles covered in our cloud application work. Knowing your gross margin per plan is what turns a product into a business.
How the engagement runs
How we sequence a SaaS build toward the first paying customer
The measure of progress in SaaS development is not features shipped, it is whether a stranger can sign up, get value and pay without anyone from your team touching the process. So we sequence work toward that end state rather than building the full vision and adding commerce at the end.
- 01Positioning and scopeThe one job the product does better than a spreadsheet, and the features explicitly deferred
- 02Tenancy and identityIsolation model, authentication, roles, invitations and single sign-on if enterprise buyers are in the plan
- 03Core workflowThe thing customers pay for, built end-to-end and usable by real people
- 04Billing and entitlementsPlans, trials, proration, dunning, tax invoices and a self-service upgrade path
- 05OnboardingSignup, sample data, the first useful action reached quickly and email sequences that respond to behaviour
- 06InstrumentationActivation, retention and per tenant usage tracked so you can see who is at risk before they cancel
- 07Beta with real customersA controlled group paying real money, because free users give polite and useless feedback
- 08OperationsMonitoring, tenant support tooling, backup restore drills and an incident process
Two decisions on your side that keep the project moving
The early releases deliberately keep some things manual. Provisioning by hand for the first handful of customers is fine and teaches you what onboarding actually needs. Automating a process you have not run yet is a reliable way to build the wrong thing twice.
Choose the right level
Choosing a tenancy model you will not regret
Tenancy is the decision that quietly governs your cost per customer, your ability to sell to a nervous enterprise buyer, and how painful a restore is when one customer deletes something important. There are three common shapes and each is right for a different business. Getting it wrong is recoverable, but the migration is genuinely unpleasant and always happens at the worst time.
Model
01
Shared schema with a tenant column
Suits
Volume products with many small customers and similar needs
The cost you accept
Every query must be tenant scoped, and one missed filter is a data leak
02
Schema per tenant
Suits
Mid market products with moderate customer counts and some per tenant variation
The cost you accept
Migrations run many times, and tooling has to handle that reliably
03
Database per tenant
Suits
Enterprise or regulated buyers who require demonstrable isolation
The cost you accept
Materially higher infrastructure cost and operational complexity per customer
04
Regional isolation on top of any model
Suits
Buyers with data residency conditions in contracts or tender documents
The cost you accept
Duplicated infrastructure and a deployment process that has to be genuinely automated
How we work this out during scoping
The pressure to choose the heaviest option usually comes from imagined enterprise requirements rather than real ones. Before designing for a database per tenant, look at who you are actually selling to next year. A vertical product serving Australian allied health clinics has different obligations from one selling into a bank, and building bank grade isolation for clinic sized revenue is how a runway disappears.
The security questionnaire your first enterprise buyer will send
At some point a larger Australian customer will send a vendor assessment. It will ask where data is stored, who can access it, how access is logged, how you handle a breach under the Notifiable Data Breaches scheme, what your backup and recovery objectives are, whether you support single sign-on and enforced multi factor authentication, and what happens to their data when the contract ends.
Every one of those is cheap to design in and expensive to bolt on
Every one of those is cheap to design in and expensive to bolt on. We build tenant scoped audit logs, role-based access, exportable data in a usable format, documented recovery objectives that have actually been tested by performing a restore, and Australian region hosting where residency is a condition. single sign-on and enforced multi factor authentication belong in the roadmap before the first enterprise conversation rather than after it. Keeping a short written security overview and a completed standard questionnaire on hand turns a three week procurement delay into a same day reply, and that is a sales advantage more than a compliance chore. Where a buyer demands deeper assurance, we scope it with dedicated security work rather than improvising.
When you should not build a SaaS product yet
If you have not sold the thing manually, do not build it. The strongest signal we look for is a service you already deliver by hand for paying customers, where the constraint is your own time. That business has proven demand and a founder who knows the domain. A product built from an idea nobody has paid for yet is a much longer odds bet, and SaaS development is an expensive way to test a hypothesis you could test with a landing page and a few conversations.
The rest of the answer
It is also the wrong shape when you only ever have one customer, which is custom software with extra steps and none of the benefits. If the need is an internal tool for your own staff, build that instead and skip the billing, signup and tenancy work entirely. And if what you really want is a marketplace connecting two sides rather than a subscription tool, the economics and the build are different enough that marketplace development is the honest starting point. We would rather say this early than take the larger engagement.
How we scope it
Four ways to scope your SaaS Development project
We do not publish package prices, because the same brief can be a short build or a long one. These are the shapes the work usually takes. Tell us which one sounds like you and you will get a fixed written quote that spells out exactly what it covers.
SaaS Discovery build
A scoped build with the architecture settled first
Fixed written quote, agreed before work starts
- Tenancy and isolation model documented and implemented
- Authentication, roles, invitations and tenant administration
- Subscription billing with trials, proration and dunning
SaaS Product build
A working product your customers or staff use daily
Fixed written quote, agreed before work starts
- Everything in SaaS Discovery build
- Entitlement service governing plan based access
- Usage metering with defensible counters
- Self-service onboarding and behaviour driven email sequences
SaaS Platform build
A platform with SSO, audit trails and a security review
Fixed written quote, agreed before work starts
- Everything in SaaS Product build
- Per tenant usage, activation and retention analytics
- Cost per tenant model with tagged infrastructure
- Security overview and completed vendor questionnaire template
SaaS Product care
A named engineer, a roadmap and real service levels
Rolling monthly, quoted in writing
- A named engineer rather than a ticket queue
- A roadmap you set, worked through each month
- Dependency patching, monitoring and incident response
- Rolling, cancel with 30 days notice
These are shapes, not menus. Most quotes end up somewhere between two of them, and we will say so when the honest answer is the smallest one. Describe the problem and we will tell you which it is.
Questions buyers usually ask
Frequently asked questions
Scope and timeline
How long before we can charge our first customer?
A focused product usually reaches paying beta customers in about 20 to 30 weeks, with a full commercial release by around 40 weeks. The single biggest lever is scope discipline. Products that launch on time are the ones where the founder can name the three things the product does and everything else is written on a deferred list. Billing and onboarding are what extend the timeline more than core features.
Can you take over a product another team started?
Often, yes. We begin with a paid technical review covering the tenancy model, data isolation, test coverage, dependency currency and deployment process, then give you a written assessment with a recommendation. Sometimes it is a straightforward pickup. Occasionally the isolation model is unsafe and needs addressing before anything else. You get the assessment either way and you are free to act on it elsewhere.
Ownership and handover
Do we own the product and the customer data?
Completely. The codebase sits in your organisation, cloud and payment provider accounts are opened under your business with your ABN, and all customer data belongs to you. We work as collaborators with access you can revoke. This matters more in SaaS than elsewhere, because your product is your company asset and any investor will look closely at whether you actually control it.
What ongoing work does a SaaS product need after launch?
More than a website and less than people fear. Expect dependency patching, monitoring and incident response, support tooling for your team, and a steady stream of product changes driven by what customers actually do. Most clients run a continuous arrangement with a fixed monthly capacity, since a SaaS product that stops improving starts churning. Some build an internal team over time and we hand across progressively.
Detail and edge cases
What does it cost to build a SaaS product?
It depends on the tenancy model, how much of the billing and entitlement logic you need at launch, whether enterprise requirements such as single sign-on are in scope, and how much of the workflow is genuinely novel. We scope a first release deliberately narrow and quote it in writing, then quote later stages separately so you can fund the product against real traction rather than committing to everything up front.
How do you handle GST and invoicing for Australian and overseas customers?
Australian customers get GST applied and compliant tax invoices generated automatically with your ABN. Overseas customers are handled separately since the treatment differs, and the billing provider is configured to record what is needed for both. Revenue data flows into your accounting system rather than being reconciled by hand each month. Your accountant should confirm the treatment for your specific circumstances, and we build to their advice.
Related services
Scope a first release you can actually sell
Tell us what you deliver manually today and who pays for it. We reply within one business day with a view on the smallest version worth building and a fixed written quote.