SaaS and subscription products

The short version

The best SaaS products rarely start as ideas. They started as a tool somebody built to run their own business, which then had four people in the same industry asking whether they could use it too. If that has happened to you, you are in a stronger position than most funded startups, because you already know the problem is real and you already know who pays for solving it.

• Existing demand beats a good idea. Four people asking to buy it is worth more than any market research.

• A first version needs multi-tenancy, billing, onboarding and support built in — that is what makes it cost more than an internal tool.

• A paid pilot for a few named customers is $15,000 to $30,000. A first version worth charging for is $30,000 to $80,000 and three to six months, depending on whether you start from an internal tool or from scratch.

• The ongoing cost is the part people underestimate. A product is a commitment, not a project.

• We take a small number of these a year, because they need real attention rather than a slot.

A product, or a favor

The honest way to find out costs almost nothing and most people skip it. Before writing any code, take the tool you already run your own business on and let three or four people in your industry use it — even if it is ugly, even if you have to set it up for them by hand.

What you are watching for:

• Do they use it after the first week, without being reminded?

• Will they pay? Not "would you pay" — an actual invoice, actually settled.

• Do they want the same thing you do, or does each one want something different?

• Can they get value without you personally explaining it to them?

• Is the problem urgent, or merely annoying? Annoying does not renew.

That fourth question is the one that decides whether you have a product. If every customer needs a call with you before it works, you have a consultancy with software attached — which can be an excellent business, but it is priced and built completely differently.

It is also common and entirely reasonable to conclude at this point that the answer is no. Finding that out for the cost of a few weeks of your own time, instead of a six-figure build, is a good outcome.

What a first version actually needs

More than the internal tool you already have, and this is where the budget difference comes from. An internal tool trusts its users, gets fixed in person when it breaks, and never has to explain itself. A product cannot rely on any of that.

What has to be there on day one:

• Multi-tenancy — every customer's data properly separated, enforced in the code rather than remembered by convention.

• Accounts, roles and invitations, so a customer can add their own staff without contacting you.

• Billing — plans, trials, upgrades, downgrades, proration, failed payments and dunning. This is always bigger than it sounds.

• Self-serve onboarding — sign up, get to something useful, and understand what to do next, with no help from you.

• Support tooling on your side — the ability to see what a customer sees so you can answer their question in a minute.

• Metrics you will actually run the business on: signups, activation, churn, revenue.

Two of those quietly dominate the estimate. Billing is a genuine subsystem, not a Stripe button, once you allow for someone upgrading mid-month or a card failing on renewal. And support tooling is the one always cut from a first version by people who have never run one — without it, every question costs you an hour.

What can wait

Plenty, and cutting the right things is what gets a first version out in months rather than years.

• A public API. Build it when a customer asks and will pay for the integration.

• Every pricing tier. Ship one plan, or two. Tiers are a pricing experiment you cannot run without customers.

• A mobile app. A responsive web application covers most business software, at a fraction of the cost.

• Single sign-on and enterprise security reviews. These arrive with enterprise customers; build them when one does.

• Infrastructure sized for a scale you do not have. Boring hosting handles more than people believe.

• Deep configurability. Every setting is a permanent support cost and a decision you have avoided making.

The exception to all of this is data separation. Multi-tenancy retrofitted onto a system that assumed one customer is close to a rewrite, and the failure mode — one customer seeing another's data — is the one mistake a young product does not recover from. That gets done properly on day one.

What it costs to build

More than an internal tool doing the same job, for the reasons above. These are the ranges we quote from before a scoping call refines them.

That last row is the one we would usually point you at. A pilot for four customers who have agreed to pay is a far better use of $20,000 than a full product for a market you are guessing at — and if it works, it funds the rest with evidence attached.

Budget for the running costs too: hosting, the payment processor's percentage, transactional email, monitoring, and ongoing development. A product that stops being developed starts losing customers within a year, and that is a permanent line in your P&L rather than a project cost.

How the data gets separated

There are two sane answers and one common mistake. The mistake is deciding this late.

For almost every product a small business launches, the shared approach is right, provided the tenant scope is applied globally rather than remembered query by query. We build it so that forgetting is not possible — the boundary is enforced in one place, and tested as its own thing rather than assumed.

Why we only take a few of these

Because a product is a relationship rather than a delivery. The interesting decisions arrive after launch — what the first ten customers ask for, what they churn over, which plan they actually buy — and those need people who know the codebase and can respond in days.

Taking on more than a few at a time would mean staffing them the way agencies do, with a team you never meet. A small number a year, given senior attention, is what decides whether they work. If we are full, we will say so instead of stringing you along.

The strongest opening is not a pitch deck. It is: here is the tool we built for ourselves, here are the four businesses that asked to use it, and here is what they currently pay to do without it.