What I've learned building SaaS products from zero

I find it easy to get interested in how a product could work before I've established why anyone would use it. A promising architecture can keep me busy for days. It doesn't tell me whether the problem is worth solving.

Building SaaS products has made me more suspicious of that kind of progress. These are the decisions I try to settle before the implementation takes over.

Find out what happens without your product

Asking someone whether they'd use an idea usually produces a polite answer. Asking how they dealt with the problem last week is more useful.

What did they open? Who did they ask? Was there a spreadsheet, a manual export, a task they abandoned? If possible, ask them to show you. The workaround tells you something about both the inconvenience and the effort they're willing to spend on it.

I want to understand the existing process well enough to describe where a new tool would fit. “Better analytics” is too vague. “An account manager needs to spot which customers stopped using a feature before their renewal call” gives me something to build and a person to test it with.

Use a stack you can maintain

I reach for Next.js because I know it. Familiarity lets me spend more time on the product and less time discovering how the framework handles routine work.

That isn't a reason to ignore requirements. A tool that must work offline has different constraints from a reporting dashboard. Data residency, integrations, and deployment costs can rule out an otherwise comfortable choice.

For a conventional SaaS application, I'd start by checking whether Postgres, an established auth library or provider, and a supported billing service cover the requirements. I'd also check their limits: supported countries, account recovery, data export, and what happens when a webhook arrives twice. Choosing a familiar service doesn't remove those responsibilities.

Decide what the first release must get right

“Ship something ugly” is advice I don't quite trust. An unfinished settings page is different from a payment form that leaves someone wondering whether they've been charged.

The first release can have fewer features and plain styling. The task it promises should work, failures should be understandable, and private data should stay private. Those are release requirements.

I cut optional configuration, secondary views, and features that only matter at a larger scale. That leaves room to finish the part someone came for.

Treat the price as a decision to test

A server bill doesn't tell you what a product is worth to a customer. Neither does the amount of time you spent building it.

I look at the job the product replaces, the available alternatives, and who has authority to pay. Then I need evidence: do suitable customers accept the offer, use what they bought, and renew?

A free tier, a trial, and a paid pilot answer different questions. A trial only helps if someone can reach a useful result before it expires. An annual discount brings cash forward, but it can also delay the moment you find out whether people would renew. None is an automatic fix for weak demand.

Leave time to find customers

Writing, direct outreach, search, and partnerships can all work. They need different amounts of time and suit different buying habits. A launch-day traffic spike doesn't tell me much unless I can see what those visitors did afterwards.

For an early product, I'd choose one plausible way to reach the people already dealing with the problem, then reserve time for it alongside development. I'd track where useful conversations came from and whether those people returned to the product.

Before committing another month, I want a reason beyond the amount of code already written. A customer returning to finish real work is one. An increasingly elaborate roadmap isn't.