Planning a SaaS? What to decide before you pay anyone to build it

Most SaaS products that fail don't fail because of the code. They fail because they were built for a problem nobody pays to solve, because the first version tried to do everything, or because nobody budgeted for running it once it was live.

I build and run a SaaS used by 10+ paying businesses, and I build products for founders. This is what I'd want any founder to settle before paying me, or anyone else, to write a line of code.

Does it need to be a SaaS?

A SaaS is software people sign in to and pay for every month. That suits a problem they have again and again: taking bookings, sending invoices, tracking stock, managing members. If your customers only have the problem once, a one-off tool, a website or a service you deliver yourself may earn more for less work.

Three questions help:

• Do they have the problem every week? A monthly price only feels fair for value that keeps arriving.
• Are they already paying to solve it? With money, staff time or a spreadsheet someone hates. That's what you're really competing with.
• Can you name ten of them? Not a market size. Ten people or businesses you could message today.

If you can't answer the last one yet, that's the first job, and it comes before any building.

Make version one smaller than feels comfortable

The first version has one purpose: to find out whether people will pay. Anything that doesn't help answer that can wait.

Try describing the product in one sentence: it lets who do one job without the pain they have today. Every feature in version one should serve that sentence. Reports, integrations, a phone app and a settings page with twenty options mostly belong in version two, once real customers have told you which of them matter.

Smaller is also faster. A focused first version can be in customers' hands in weeks rather than months, and every week earlier is a week spent learning instead of guessing.

Budget for running it, not just building it

Building it is a one-off cost. Running it costs money every month, and that's the part founders forget:

• Hosting and services. Servers, storage, sending email, backups and monitoring.
• Payment fees. Card processors take a share of every payment you collect.
• Support. Someone answers customers, fixes what breaks and handles "I can't sign in".
• Updates. Browsers, phones and the libraries underneath keep changing, and software nobody maintains slowly breaks.
• Your own time. Sales, getting new customers started, and the calls that tell you what to build next.

Ask whoever builds it what it will cost to run each month at ten customers and at a hundred. A clear, unhurried answer is a good sign.

Price it simply

Start with a price people understand without asking. A flat monthly price per business, or per user when more users really means more value, is easier to sell than a calculator. Offer a yearly plan at a discount too, because it improves cash flow and keeps customers longer.

Don't price on what it cost to build. Price on what the problem costs your customer today, in money or hours, and charge a fair share of that. Lowering a price later is easy. Raising it on the customers you already have is much harder.

Own what you pay for

Before any money changes hands, get these in writing:

• You own the code once it's paid for, and you can see where it's kept.
• The domain is registered in your name.
• The hosting, payment and email accounts are yours, or can be moved to you.
• Your customers' data can be exported whenever you ask.
• It's agreed what happens if you and the developer part ways.

None of this is a sign of distrust. Any developer worth working with will agree to it straight away.

Choosing who builds it

Building a SaaS isn't the same as building a website. The work that decides whether it succeeds starts after launch: payments that fail, customers who need help, things that break at the worst moment. So look for someone who already runs software that people pay for.

These questions separate the two quickly:

1. "Can you show me a product you built that people pay for today?"
2. "What broke after launch, and how did you find out?"
3. "What will it cost to run each month, and who pays for that?"
4. "How would I get my data out if I needed to?"
5. "What's included after launch, and what does support cost?"
6. "What would you leave out of version one, and why?"

The last question matters most. Someone who pushes back on your feature list is protecting your budget.

Are you ready to brief a developer?

A good plan doesn't need to be long. It needs to say who it's for, what the first version does, what you can spend to build and run it, and what you'll own at the end. With that, a good developer can give you a fixed price and a date, and you'll be able to tell which quotes are realistic.

If you have an idea and want to talk it through, that's the kind of work I take on.