Development Agency
Contact Sign in Get a project quote

Service

SaaS Development

For founders and established businesses turning a process they know well into subscription software that other organisations will sign up to, pay for and run their own work in, without each customer becoming a separate project.

Get a project quote

The problem

What goes wrong today

Where it usually starts

The people who come to us for SaaS development usually fall into two groups.

  • The first has a working prototype: a founder or a small team built something quickly, a handful of early customers are using it, and now every customer's data sits in the same tables with a column that is supposed to keep them apart.
  • Billing is a spreadsheet and a payment link.
  • A new customer means someone creating accounts by hand, and a feature request from the largest customer means a special case in the code that nobody dares remove.
  • One slow query from one customer slows everyone down, and there is no way to tell which customer caused it.

Where it gets harder

The second group runs a business whose internal system has become good enough that other companies in the same trade have asked to use it.

  • They know the domain thoroughly, but the system assumes one company, one set of users and one way of working, and has never charged anyone, handled a trial, downgraded a plan or deleted a customer's data on request.
  • Both groups need the same things: isolation between tenants that is enforced in code rather than hoped for, plans and billing that handle the awkward cases, roles and permissions per organisation, onboarding that does not need a person, and a way to upgrade the whole system without breaking anyone.

Scope of the service

What the build covers

A SaaS build normally covers the tenant model, the account and billing lifecycle, the application itself and the operational tooling around it. The tenant model decides how organisations, their members and their data are separated: every query scoped to the organisation, membership and ownership checked on every request, and an isolation test suite that proves it. Plans are configured, not coded: features and limits per plan, trials, upgrades and downgrades with proration rules you set, cancellation and reactivation, failed payment handling and invoices, all through the provider-independent payment layer with hosted checkout, so card details never touch the application. Roles and permissions are defined per organisation, with an owner who can invite, remove and transfer. Onboarding takes a new organisation from sign-up to first useful action without anyone from your team involved.

The application layer is built as a modular monolith first, with the domain rules in one place shared by the web interface, any API and scheduled jobs, so a rule exists once. Operationally the build includes an admin panel for your team, audit logs, data export and deletion per organisation, background jobs with retries, and monitoring.

When the scope grows

Scoping scenario

A recruitment consultancy wants to offer the applicant pipeline it built for itself to other agencies as a subscription, with three plans, per-seat pricing above a base, a free trial, and each agency's data invisible to every other. The tenant model, the seat-based billing and the migration of the consultancy's own data into the first tenant make this a build, and the scope document sets out each part.

Deliberately out of scope

  • Your pricing strategy and go-to-market, legal terms and privacy policies (we implement what your advisers write), native mobile applications, and operating the service for you, which the maintenance and hosting service covers separately

Deliverables

What you receive

  • Discovery notes covering the domain, the tenant boundaries, the plans you intend to sell and the awkward billing cases
  • A written scope document naming the modules, roles, plan features and limits, and what is left out
  • Designs of the onboarding flow, the main working screens and the account and billing area on mobile and desktop
  • The build, deployed to your hosting or ours, with the payment provider connected and the isolation suite passing
  • Migration of your existing data into the first tenant where a prototype or internal system exists
  • An admin panel for your team with audit logs, organisation management and support tooling
  • Handover material and full ownership of the source code and your data

Process

How a project runs

Each stage maps onto the project view in your client panel. Durations are set in your proposal, never on this page.

  1. Onboarding

    Access to the prototype or internal system, its data and the payment provider account; a review of how customers are set up and charged today.

    Project stage: Onboarding

  2. Planning

    Discovery on the domain, the tenant model and the plans; modules, roles and billing rules are written into the scope document.

    Project stage: Planning

  3. Design

    Onboarding, the daily working screens and the account area designed for the users your customers will have, phone width first.

    Project stage: Design

  4. Development

    Tenant model, identity and roles first, then the application modules, then plans, billing and the admin panel.

    Project stage: Development

  5. Client review

    You and a few early customers sign up, run real work and move between plans with the payment provider in test mode.

    Project stage: Client review

  6. Revisions

    Changes from the review are made and re-checked, including the isolation and billing test suites.

    Project stage: Revisions

  7. Ready for launch

    Existing data migrated into the first tenant, live payment account verified under your control, monitoring and backups in place.

    Project stage: Ready for launch

  8. Delivered

    Customers sign up and pay; hosting, maintenance and a feature roadmap continue under their own agreement if taken.

    Project stage: Delivered

Integrations

Commonly integrated

Systems this kind of business usually asks us to connect. Each integration is confirmed during discovery; none is assumed.

  • Card and direct debit payment providers through the provider-independent payment layer
  • Transactional email and SMS providers for invitations, receipts and notifications
  • Accounting software for invoices, credit notes and settlement
  • Single sign-on providers where your customers require it
  • Calendar, document and storage services your customers already use
  • Support desk and status page tooling for your team
  • Analytics and product usage measurement with consent handling

How we would approach it

Worked example

Concept demo

A recruitment consultancy offering its applicant pipeline to other agencies

The situation

A consultancy has run its own applicant pipeline for three years and wants to sell it as a subscription to other agencies, with three plans, a free trial, per-seat pricing above a base number of users and complete separation between agencies.

Why it is a custom build

The custom route is needed because the consultancy's pipeline rules are the product itself, and the tenant model, seat billing and migration have to be designed around them rather than fitted into a generic template.

The scope we would propose

  • An organisation-scoped tenant model with an isolation test suite
  • Plan configuration with feature flags and seat counting
  • Hosted checkout and self-service billing through the payment provider
  • Owner, manager and consultant roles per agency
  • Self-service onboarding that imports a spreadsheet of candidates
  • An admin panel for the consultancy's own team
  • Migration of the consultancy's historical data into the first tenant

Concept demo: a scoping scenario written to show how we would approach the work. It is not a delivered client project.

Pricing

What affects the price

Every proposal is priced on scope. These are the factors that move it most for this kind of build.

  • Breadth of the application: how many modules and screens the first release needs
  • Complexity of the plan structure: trials, seats, usage limits, proration and discounts
  • Roles and permissions per organisation and any single sign-on requirement
  • Whether a prototype or internal system exists and how much of its data is migrated
  • Public API and third-party integrations required at launch
  • Compliance needs such as data export, deletion, retention and audit requirements
  • Admin and support tooling for your team
  • Hosting choice: your own hosting or ours

Start from a package

  • Software package

    Membership platform package

    Tiered plans with a benefits matrix, trials and prorated upgrades, gated content and community, recurring billing with retries and dunning, coupons and churn reporting for membership businesses and paid communities.

    Custom build

  • Software package

    Applicant tracking package

    Requisition approval, career site with forms per role, configurable pipelines, panel interview scheduling, scorecards, offer letters, candidate templates and hiring reports for in-house teams.

    Custom build

  • Software package

    Quote and invoice package

    Quote builder with optional items and expiry, online acceptance with signature, conversion to deposit and balance invoices, payment links, bank transfer matching, credit notes, overdue reminders, branded PDFs and a client document portal for small businesses, trades and consultancies.

    Custom build

FAQ

Frequently asked questions

Why build a monolith first rather than microservices?

Because a single well-structured application is faster to build, easier to change and cheaper to run until a measured need says otherwise. The domain rules live in one place and are shared by the web interface, the API and scheduled jobs. Modules are kept separate inside the codebase, so a part can be split out later if traffic or team size requires it.

How is each customer's data kept separate?

Every record belongs to an organisation and every query is scoped by it; membership and ownership are checked on the server on every request, never trusted from the browser. An isolation test suite exercises these rules and runs on every change, so a regression is caught before it reaches customers.

Can you handle trials, upgrades, downgrades and failed payments?

Yes. Plans, trials, proration and dunning rules are configuration, and billing runs through a provider-independent payment layer with hosted checkout, so the provider can change later. Webhooks are verified, de-duplicated and handled out of order, and nothing is marked paid from a browser redirect.

Is there a package that already covers some of this?

Where the product is close to one of our packages, we start there and customise. The membership platform package covers plans, gated content and member accounts; the applicant tracking package and the quote and invoice package are examples of business software that can be offered to several organisations. The proposal states which route fits.

Who owns the software and who runs it?

You own the source code and all customer data. Running the service, with updates, backups and monitoring, is optional and agreed separately under the maintenance and hosting service, or your own team can take it on.

Get a project quote for saas development software

Answer a few questions about your business, your current systems and what should change. We reply with a clear, competitive proposal.

Get a project quote Discuss a partnership
Get a project quote

Cookies on this site. Strictly necessary cookies keep the site working. Allow first-party analytics so we can see which pages lead to enquiries. No advertising, no third-party trackers, no personal data; you can change this at any time on the cookies page.

Manage preferences