What I've learned building SaaS products from zero

I've started more SaaS products than I can count. Some worked. Plenty failed. The failures taught me more than the successes, though at the time they mainly 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 confirmed 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. Do it before the MVP exists.

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.

Stack choice matters later

I've built products in half a dozen different stacks. For many SaaS products, the technology choice barely matters in the first year. Iteration speed matters more.

I use Next.js for nearly everything now because I know it deeply and can move fast with it. The productivity advantage of using familiar tools 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 nearly every product.
Authentication. Rolling your own auth is always a mistake. Use NextAuth, Clerk, or something similar.
Billing. 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. Some of the features that worked best 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's made. And if they do want it, they'll forgive the rough edges while you polish it.

Design matters. The important distinction is intentional simplicity versus 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. Plenty of founders do the same. 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 harder

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

Things that have worked for me:

Writing about the market 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 work.
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 many 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. Skip the formal accountability structure. Find friends who understand what you're going through because they're going through it too.

A 5-minute conversation with someone who gets it can be worth more than 10 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. Talent, funding, and the perfect idea all matter less than the willingness to keep going when things aren't working.

Plenty of 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.