5 Conversations Every SaaS Founder Should Have Before Writing Code

The Most Expensive Code Is Code You Didn’t Need to Write

I’ve watched founders burn three, six, even twelve months building something nobody wanted. Not because they were bad engineers. Because they skipped the conversations that would have told them what to build, what to skip, and whether to build at all.

Before you write a single line of code, have five conversations. They’ll take a week or two. They’ll save you months.

Conversation 1: Five Potential Users About the Problem

Not about your solution. About the problem.

Find five people who you believe have the problem you want to solve. Don’t pitch them. Don’t show them mockups. Just ask about their current workflow and where it breaks down.

What to ask:

• “Walk me through how you handle [process] today.”
• “What’s the most frustrating part?”
• “How have you tried to fix it?”
• “What does this problem cost you in time or money?”

What to listen for: Are they describing the problem with emotion, or is it just a minor annoyance? Do they already have workarounds? How much effort have they put into solving it themselves?

If five people describe the same pain in similar terms, you’re onto something. If they all shrug and say “it’s fine, I guess,” reconsider.

The critical thing here: don’t mention your solution during these conversations. The moment you pitch, people stop telling you the truth and start being polite.

Conversation 2: Your Technical Cofounder or CTO About Feasibility

If you have a technical partner, sit down and talk through the core technical risks before committing to anything.

What to discuss:

• What’s the hardest technical problem in this product?
• What are we uncertain about?
• Where will we need third-party services versus building our own?
• What’s the minimum we could build to test the core assumption?

What to listen for: Where does your technical person hesitate? What makes them say “that depends”? Those are your risk areas. Better to find them now.

If you’re a solo technical founder, have this conversation with yourself, but be brutally honest. Write your concerns down. The act of writing makes it harder to hand-wave.

Conversation 3: Someone Who Tried to Solve This and Failed

This one is harder to arrange, but it’s gold. Find someone who built a product in the same space and didn’t make it. Buy them a coffee. Ask what happened.

What to ask:

• “What was your original thesis?”
• “When did you first realize it wasn’t working?”
• “If you could do it over, what would you change?”
• “What do you know now that you wish you knew at the start?”

What to listen for: Patterns. Was it a distribution problem? A pricing problem? Did they build too much before validating? Were they solving a problem people said they had but wouldn’t pay to fix?

These conversations are humbling and incredibly valuable. The failure patterns in your space are usually well-known to people who’ve experienced them.

Conversation 4: A Competitor’s Customer About What’s Missing

If competitors exist (and they almost certainly do), find someone who uses a competing product. LinkedIn is great for this. Most people are willing to chat for 15 minutes about tools they use at work.

What to ask:

• “What made you choose [competitor]?”
• “What do you wish it did differently?”
• “What’s your biggest workaround?”
• “If you could change one thing about it, what would it be?”

What to listen for: The gaps. Not the minor complaints, but the structural limitations. “I wish it integrated with X” is a feature request. “I export everything to a spreadsheet because their reporting can’t do what I need” is a gap you can build a product around.

If the competitor’s customers are mostly satisfied, that’s important data too. It means you’ll need a strong differentiator, not just a slightly better version of the same thing.

Conversation 5: Yourself, Honestly, About Why You’re the One to Build This

This is the conversation most founders skip. Sit down with a blank page and answer these questions:

• Why am I the right person to solve this problem?
• Do I have an unfair advantage (domain expertise, distribution, technical edge)?
• Am I willing to work on this specific problem for 3 to 5 years?
• If a better-funded competitor copies my approach in 6 months, what’s my moat?
• Am I building this because I’m excited about the problem, or because I’m excited about being a founder?

Be honest. There are no wrong answers, but there are answers you need to face before investing a year of your life.

Turning Conversations Into a Plan

After these five conversations, you’ll have something most founders lack when they start coding: context. You’ll know the real shape of the problem, the technical risks, the market gaps, the failure patterns, and your own motivations.

The next step is capturing all of that into a structured product spec before you build. Tools like Projan are designed for exactly this: you talk through what you’ve learned, and it helps you structure it into a clear plan with user stories, priorities, and scope boundaries.

Start building your spec. The conversations gave you the insight. Now turn it into something you can execute against.

You can’t shortcut the conversations. But you can make sure the insights from those conversations don’t get lost in a pile of scattered notes. Write the spec, then write the code.