I’ve built a few SaaS products now. Some worked. Some didn’t.

If I had to start again today — clean slate, zero lines of code — this is exactly how I’d do it.

No hype. No fluff. Just the stuff I wish I knew earlier.

1. Pick a boring market that already has demand

You’ll have more luck picking a boring market that already has product–market fit.

Not AI prompt tools. Not a crypto-powered task manager. Just a market where people already pay for solutions, complain about those solutions, and are actively looking for better ones.

That’s where the gold is.

If I were starting over, I’d spend my first week doing deep research:

• Make a list of the top 5–10 tools in a specific vertical (like support tools, internal dashboards, CRMs)
• Study their landing pages and pricing
• Dig through their review sites, Twitter mentions
• Reach out to a few customers and just ask what they love, hate, and wish they could change

Look for patterns in the complaints — recurring pain points. Pick a few of the biggest ones and build something that’s intentionally simple and focused on just those.

You don’t need to create a new market or invent something never seen before.

You just need to slot into an existing one with a better experience, better customer service, and enough clarity to win over early users.

2. Talk to customers — a lot

Every user is worth more than just their monthly payment.

They bring ideas, context, edge cases, and sometimes even your next best feature idea — just not in the form you expected.

One of the most powerful things you can do early on is create a tight feedback loop. Make it easy for users to leave feedback, and make them feel comfortable doing it. Whether it’s a short email reply, a message in your widget, or a public suggestion — the feedback is gold.

I built UserJot to solve exactly this. It gives you a clean public board with upvotes, categories, and a way for users to see what’s being worked on. You can use any tool really, but the key is: make your customers part of the process.

And don’t just listen to compliments.

“The UX is confusing.”

“I didn’t realize I could click that.”

“This integration broke.”

Those messages matter far more than “I love this!”

Sometimes your best product decisions come from the smallest friction points.

3. Don’t aim for a big launch

Let’s be honest — most “launches” don’t matter anymore.

Product Hunt is gamed to death. Unless you have a huge existing audience or a hype squad, it’s not likely to move the needle.

Don’t waste weeks prepping for a single day of artificial momentum.

Instead, launch constantly:

• Ship something small? Post about it.
• Add a new feature? Write a thread.
• Get your first 10 users? Share the journey.

Marketing is a compounding game.

Sometimes a tweet brings in 20 signups.

Other times you post and no one reacts.

That’s normal. Keep showing up.

The key is to try different things — Twitter, LinkedIn, blog posts, YouTube, indie communities — and figure out which ones bring real users. Then double down on those.

Also: don’t fake anything. No inflated numbers. No made-up testimonials. No spammy DMs. People can smell the desperation from a mile away, and it kills your reputation before you’ve even started building one.

Be genuine. Be small. Be consistent.

4. Don’t “launch.” Just drip.

Instead of treating your product like it needs a giant reveal, treat it like a living thing you’re slowly introducing to the world.

Talk to people individually. Post your progress online. Share what you're learning, struggling with, and fixing.

This approach creates something more powerful than launch day hype: trust.

By the time someone signs up, they’ll feel like they’ve watched your story unfold — and they’ll be rooting for you.

If you can get even five users to deeply care about your product, you’re off to a great start. Don’t underestimate that.

5. Keep the stack simple

Whatever you’re thinking of using — simplify it.

If you don’t need it today, don’t build it in.

You’re not building for Netflix scale. You’re probably going to have 10–50 users in your first few weeks. Optimize for speed, not scale.

Pick tools you’re fast with. Use whatever lets you:

• Ship fast
• Change things without breaking your soul
• Avoid unnecessary complexity

That might be a monolith. That might be serverless. It doesn’t matter.

What matters is that you don’t waste weeks setting up Kubernetes clusters or writing custom CI pipelines when no one’s using your app yet.

Your MVP will be messy. It will have bugs. That’s okay.

Focus on functionality, UX clarity, and feedback-driven iteration. You can clean up later.

6. Say no more than you say yes

Your first customers will have lots of ideas. Some of them will be good.

Many won’t be.

You’ll get requests like:

• “Can you add this one-off integration?”
• “We’d use it if you also supported XYZ workflow.”
• “This would be perfect for my team of 35 if it had just this one extra dashboard…”

It’s tempting to say yes to all of it — especially if it means closing a sale. But don’t.

Say no to things that don’t align with your core product.

Say no to building complex features for one user unless you’re okay supporting it forever.

Say no when a feature bloats your app, distracts your roadmap, or adds risk you can’t afford yet.

Saying no protects your speed and your sanity.

Saying yes too much is the fastest way to hate your own product.

7. Charge from day one

“Free while in beta” feels like a low-pressure way to start, but it’s a trap.

You’ll attract users who were never going to pay. You’ll convince yourself your product is validated. And then when it’s time to put up a paywall, those users vanish.

It’s better to charge early — even just $5 or $10 a month — and know that you’re solving something valuable enough for someone to pay for it.

And honestly, charge more than you think you can. If you’re solving a real problem, people will pay. If they won’t, you need to reevaluate the problem, not the price.

8. Set up a feedback board on day one

Feedback is easier to gather when users see that you actually care. A changelog is nice. A roadmap is helpful. But a public board where people can see that you’re listening? That’s what builds loyalty.

Whether you use UserJot — the tool I built — or any other feedback system, the goal is the same:

• Let people post ideas
• Let others vote on them
• Show what’s in progress and what’s shipped

This does two things:

1. You build a product your customers help shape
2. You signal to future customers that you’re responsive and transparent

It’s low effort and high return. Just set it up and point people to it.

9. Spend more time marketing than coding

If I were starting over, I’d spend:

• 50% of my time on marketing — SEO, writing, posting, talking to users
• 20% on support and customer experience
• 30% on actually building features

Because the truth is, it doesn’t matter how good your product is if no one knows it exists.

Founders often spend weeks perfecting a feature, when a simple blog post, tutorial, or tweet could’ve brought in their next 10 customers.

Build the thing — yes. But then tell people about it.

And then tell them again, in a different format, on a different channel.

Marketing isn’t a separate job. It’s the second half of building.

Final thought: Make life easier for yourself

This stuff is hard. You’re juggling product, support, code, growth, and your own self-doubt. You don’t need to make it harder by picking an impossible market, building the perfect infra, or chasing vanity metrics.

Make it easier by:

• Choosing a market that’s already validated
• Solving problems people are already paying for
• Charging early
• Saying no often
• Talking to customers constantly
• Marketing consistently, even when it feels like no one’s watching

The goal isn’t to launch fast.

The goal is to build something people come back to.

This is my exact playbook I am following for UserJot. I hope you find it useful. :)

I send posts like this occasionally — join the list.