You Probably Don't Need a SaaS Development Agency

"SaaS Development Agency" Means Two Different Things

The phrase gets typed into a search bar by two completely different people, and almost nobody sorting the results bothers to split them apart.

One person is building a multi-tenant product, something sold to other companies on a subscription, with logins, billing, and a roadmap driven by a market. The other person runs operations somewhere. They've outgrown the spreadsheet or the off-the-shelf tool taped to their process, and they want something built for their company to run on. Nobody else will ever log into it. Nobody's paying a monthly fee for a seat.

Both people search the same three words. They need different things, from different kinds of shop. We work with decision-makers in the second camp: the ones who've outgrown spreadsheets or off-the-shelf tools and need something built around how they actually work, not how a market of buyers might.

Most mid-sized companies typing "SaaS development agency" into Google aren't trying to launch a product. They're trying to fix the spreadsheet everyone secretly runs the business on. We see this across logistics and freight, healthcare, field services, manufacturing, professional services, retail and e-commerce, fintech and insurance, and construction. A dispatcher tracking jobs in a shared sheet. A quoting process that lives in someone's email drafts. A finance team reconciling three systems by hand at month-end because none of them talk to each other.

None of that is a SaaS product. It's a custom web application, a portal, a dashboard, a workflow tool built for one company's process, not a thousand companies' average process. That distinction should decide who you call next, before pricing or timelines come up.

We Don't Build Multi-Tenant SaaS Products

If you're genuinely building a product to sell as SaaS to other companies, go find a specialist in that. Tenant isolation and billing infrastructure are a different discipline, and we don't do that work. Pretending otherwise to win the call would waste your time and ours.

What we build is custom web applications for internal use, the tools a company runs on, not the product it sells. We say this upfront because we turn down projects a specialist would do better, or that an existing off-the-shelf product already solves for a tenth of the price. You'll hear that in the first call, not the third, after you've already sat through a proposal.

Boring Technology, On Purpose

For the internal tools we build, the stack is deliberately unexciting: React, Node, Postgres. Not because it's all we know. Novelty is a cost paid every year after launch, and the client is the one who pays it.

Software is never finished. A workflow tool that ships and then gets ignored starts rotting the day it launches. That's why we treat ongoing care as part of the product, not an afterthought bolted on later. Our cloud, DevOps and care work covers infrastructure as code in your own cloud account, plus monthly dependency and security patching, from $4.5k a month. Boring technology is what makes that maintenance predictable instead of a rescue job three years in.

Who Owns the Code and the Infrastructure

You own the code outright from day one. Not eventually, not after a buyout clause. The repositories live in your organisation's account, not ours. The infrastructure runs in your own cloud account, not one we control and rent back to you.

There's no handoff to a junior team either. The named lead who scopes the project stays through launch. The person who understood your dispatch process in week one is the same person answering questions in week fourteen.

And if the relationship ends, whether by plan or otherwise, you get a full handover: an architecture walkthrough, runbooks written in plain language, and two weeks of support. None of this is a negotiation at offboarding. It's decided before the first line of code gets written.

How the Estimate Actually Gets Built

We don't quote off a first call. We don't know enough yet to make the number hold.

Instead there's a discovery week, flat $4,800, credited back in full if you continue with us. It ends in a written scope, an architecture sketch, and a fixed estimate, not a range with an asterisk. Estimates should come after discovery, not before. That's the only reason the number holds once work starts.

If scope changes mid-project, and it sometimes does once you see the thing working, that gets priced before the work starts. Not billed after the fact as a surprise on an invoice. It's a small thing to promise and an easy one to break, which is exactly why we write it down.

What a Custom Web Application Actually Costs

For the internal tools most readers here actually need, portals, dashboards, workflow tools, pricing starts at $45k, with a typical timeline of 10 to 20 weeks. That covers role-based access, audit trails and approvals, reporting built for your finance team, migration of your existing data, and training and documentation so the tool doesn't die the day your one power user goes on vacation.

Billing runs on milestones, typically 30% at kickoff, then the remainder as phases are accepted, so you're never paying in full for work you haven't seen. Every project includes 30 days of post-launch fixes. Invoices are Net 14.

You can find the fuller breakdown on the custom web applications page. Short version: it's a real number, attached to a real scope, before any work begins.

The Honest Disqualifier

If an off-the-shelf tool already covers what you need, or the workflow isn't complex enough to justify a custom build, that should come out in the first conversation, not after a contract's signed and a deposit's cleared. We turn down projects an existing off-the-shelf product already solves for a tenth of the price. Building it anyway wouldn't make us right, just paid.

If you're not sure which camp you're in, that's a fine reason to start small. Discovery week is a bounded, refundable first step. One paid week, ending in a document you can take anywhere.