SaaS Application in New Zealand

Why people want this so badly

Consulting income stops when you stop. Product income does not. A hundred customers paying $200 a month is $240,000 a year that arrives whether you are selling, sick, or asleep — and next year it arrives again, plus whatever you added. That is the whole appeal, and it is a completely rational thing to want.

It is also achievable at a scale most people underestimate. You do not need to be the next Xero. A product serving four hundred customers in one unglamorous industry, at a price they barely notice, is a very good business — and it is far more likely to happen than the version with a billion-dollar exit.

The part that kills most attempts

It is not the code, and it is almost never the technology. Products fail because they were built for eighteen months before anyone was asked to pay.

Every week you spend building without a paying customer is a week spent guessing. The guesses feel reasonable — you know the industry, you have talked to people, the features are obviously needed. Then you launch and discover that the thing everyone said they wanted is not the thing they will pay for, and the feature you nearly cut is the one they actually use.

The only known defence is to get something small in front of someone who pays for it, early enough that being wrong is cheap.

Start with the smallest thing worth paying for

Take the thing you want to build and find the single workflow at its centre — the one where the customer's problem actually gets solved. Build that, with accounts and billing around it, and nothing else.

It will feel embarrassing. It will be missing the reporting, the integrations, the mobile app and half the settings. Ship it anyway, to five customers who pay real money. What you learn in the first month of that will change what you build next more than another six months of planning would.

A good developer will push you toward this. If someone quotes your entire feature list without asking which part comes first, they have not run a product before.

The strongest starting point: something you already do manually

The lowest-risk SaaS is a service you already run by hand. You have customers. You know what they pay. You know exactly where the work is, because you are the one doing it in spreadsheets at 11pm.

Turning that into software removes the guessing entirely. You are not asking whether anyone wants it — you already know, because they are paying you for it now. You are only asking whether it can be delivered by software instead of by you. That is a far smaller question, and a far cheaper one to answer.

What it actually costs

A first paying version is usually $60,000 to $120,000 and three to five months. That buys one workflow done properly, signup, subscription billing, and a system built so it can change every week — because it will.

A full multi-tenant product with teams, permissions, integrations and an admin side is $120,000 to $300,000. Beyond that you are building a platform, and the cost is driven by compliance, scale and complex billing rather than features.

The running cost surprises people in a good way: hosting an early SaaS is often under $200 a month, because it scales with usage rather than ambition. The real ongoing cost is development. A SaaS product that stops changing starts dying, so budget for a continuing relationship rather than a finished project.

Read the quotes for judgement, not price

• Who suggests cutting scope? The developer who proposes a smaller first version is telling you they have done this before.
• Who asks about billing early? Trials, plan changes, failed payments and refunds are where SaaS gets fiddly. It should come up in the first conversation.
• Who owns what? Get it in writing: the code, the domain, the cloud accounts, the Stripe account. All of it should be yours.
• What happens after launch? A quote that ends at go-live is quoting a project. You are starting a product.

It is more possible than it looks

New Zealand and Australia are full of software businesses that started as one person who knew an industry well and got tired of doing the same thing by hand. They did not start with funding, a technical co-founder, or a grand plan. They started with one workflow, a handful of paying customers, and someone who would build it properly.

If you have the industry knowledge, the missing piece is a developer who has shipped a product before — not just software. Describe what you want to build and what you already know about the customers, and up to five of them will tell you how they would approach it. Comparing those answers is the cheapest research you will ever do on this idea.