What I've learned building SaaS products from zero

I've started more SaaS products than I can count. Some worked. Most didn't. The failures taught me more than the successes, though at the time they mostly just felt bad.

Here's what I know now that I wish I'd known at the start.

Start with the problem, not the solution

This sounds obvious. Everyone says it. And yet I still catch myself getting excited about a technology or an architecture before I've validated that anyone actually needs what I'm building.

With Geosaur, I spent months building a complex monitoring system before talking to enough potential users. I had assumptions about what features mattered, and some of them were wrong. The features I thought were core ended up being secondary, and the thing users actually wanted was something I'd considered "nice to have."

The fix is simple but uncomfortable: talk to people before you build. Not after. Not "I'll just build an MVP and see." Actually talk to them. Ask what they're struggling with. Watch how they currently solve the problem. Then build the minimum thing that addresses what you learned.

The stack doesn't matter (until it does)

I've built products in half a dozen different stacks. The honest truth is that for most SaaS products, the technology choice barely matters in the first year. What matters is how fast you can iterate.

I use Next.js for almost everything now. Not because it's the best framework for every use case, but because I know it deeply and can move fast with it. The productivity advantage of using tools you know well outweighs any theoretical benefit of using the "right" tool.

That said, there are decisions that are genuinely hard to change later:

• Database choice. Migrating databases is painful. PostgreSQL is the right default for almost everything.
• Authentication. Rolling your own auth is always a mistake. Use NextAuth, Clerk, or something similar.
• Billing. Stripe. Just use Stripe. The time you'd spend evaluating alternatives is time you could spend building your product.

Ship something ugly

My background in design makes this one hard for me. I want everything to look good before anyone sees it. But some of the most successful features I've shipped started as embarrassingly rough implementations.

The first version of a feature should prove the concept, not win design awards. If users don't want the thing, it doesn't matter how beautiful it is. And if they do want it, they'll forgive the rough edges while you polish it.

This doesn't mean design doesn't matter. It absolutely does. But there's a difference between intentional simplicity and premature polish. Ship the simple version first, then make it beautiful once you know people use it.

Pricing is harder than building

I've underpriced every product I've ever made. Most founders do. We're so grateful that someone wants to pay us anything at all that we set prices too low and then struggle to raise them later.

Here's what I've learned about pricing:

• Your first price is always too low. Double it and see what happens. Seriously.
• Free tiers attract the wrong users. They fill your support queue with people who will never pay. Offer a free trial instead.
• Annual pricing is worth the discount. The reduced churn and improved cash flow more than offset the lower monthly rate.
• Price based on value, not cost. If your tool saves a company 10 hours per month, charge based on what those hours are worth, not on what it costs you to run the servers.

Distribution is the real challenge

Building the product is the fun part. Getting people to use it is the hard part. I've had products that were genuinely good sit at zero users for months because I didn't think about distribution from the start.

Things that have worked for me:

• Writing about the problem space before the product is ready. This builds an audience of people who already care about what you're building.
• Building in public. Sharing progress on social media creates accountability and attracts early users who want to follow the journey.
• Direct outreach. Cold emails and DMs work better than you'd think, especially if you've done your research and can explain specifically why your product is relevant to that person.
• SEO. It's slow but compounds. Content that ranks keeps bringing in users months and years after you publish it.

What hasn't worked: Product Hunt launches (brief spike, no retention), paid ads before finding product-market fit (expensive lessons), and hoping that a good product will market itself (it won't).

The loneliness problem

Building a product solo or with a tiny team is isolating. You're making hundreds of decisions per week, and most of them you can't bounce off anyone. You second-guess yourself constantly.

The best antidote I've found is having a small group of people who are building similar things. Not a mastermind group or a formal accountability structure. Just friends who understand what you're going through because they're going through it too.

A five-minute conversation with someone who gets it is worth more than ten hours of reading blog posts about startups. Including, I suppose, this one.

Keep going

The single biggest predictor of success I've seen is persistence. Not talent, not funding, not the perfect idea. Just the willingness to keep going when things aren't working, to keep iterating when growth is slow, and to keep believing in what you're building even when it feels like nobody cares.

Most successful products had a long stretch where they looked like failures. If you're in that stretch right now, you're in good company. Keep building.