r/B2BSaaS

I'm making a product specifically for b2b agencies and businesses and an wondering where should i start looking for them?

As for now, im using dm marketing on x and insta as my distribution channel to find users*

I have:
A validated product idea
A complete PRD
A detailed MVP specification
An Architecture Decision Record (ADR)
The product scope is well defined, and I want to build and launch the MVP as quickly as possible.
My biggest challenge is hiring.
I don’t have the budget to hire a full in-house senior engineering team, but I’m also skeptical about relying entirely on interns because I feel it could take much longer and require a lot of hand-holding.
At the same time, hiring a single experienced engineer feels risky because I’m not sure if one person can realistically build the entire MVP (frontend, backend, cloud infrastructure, AI integration, database, etc.).
I’m trying to figure out the best execution strategy.
If you were in my position, what would you do?
Some specific questions:
Should I hire one experienced full-stack engineer first?
Should I work with a small development agency instead?
Is it better to hire multiple freelancers?
Would a senior engineer plus one or two interns be a good balance?
Where have you had the best experience hiring? (Upwork, Toptal, LinkedIn, Wellfound, referrals, etc.)
My goal isn’t to build the perfect product—it’s to launch a solid MVP as quickly as possible without making expensive hiring mistakes.
I’d really appreciate hearing from founders who have built SaaS products or engineering managers who’ve hired early-stage teams.
Looking back, what hiring approach worked well, and what would you avoid?
Thanks in advance!

My last few posts here did a couple 100k views combined and the most common question in my DMs since has been some version of "should I build a free tool to get users" In short, yes. Long answer…. almost everyone builds the wrong one.

Let me explain with the oldest trick in local business.

Carpet cleaners used to offer one room cleaned completely free. It probably sounds like they're giving away the product right? Well that’s wrong. Because the moment that one room is clean and spotless…. every other room in the house looks filthy by comparison. The homeowner didn't know they had a problem an hour ago but now they can't unsee it. The free cleaning of one room did not satisfy the customer. It actually made them want more.

That's what a free tool is supposed to do. Solve one NARROW problem completely…. and in doing so make the bigger problem your paid product solves impossible to ignore. I build MVPs for founders and free tools have quietly become half of my project requests this year. I have watched them become a founder's entire growth engine and I have watched them become a complete waste of a month. The difference is never the code.

Now here is where every SaaS founder makes a mistake. And I mean this literally…. the most common free tool request I get is "can you build a lite version of our product." That's not cleaning one room. That's cleaning the whole house for free and hoping they tip you. It doesn't reveal the problem it SOLVES it. Then the founder wonders why free users never upgrade…. because you already gave them everything, genius. A big part of my job  on these projects is talking the founder out of the lite version before we build anything.

After building a bunch of these, every free tool that actually converts falls into one of 3 buckets /groups.

Bucket one…. show them the dirt. Think about a diagnosis. You can offer an audit, a speed test, a calculator or a grader. You show them a number and a gap. For example you can say ,"Your site loads 30% slower than it should and here's roughly what that costs you a month." These approach work insanely well when the problem gets worse the longer they wait. I built this exact same thing for a founder with an SEO product…. free personalized audit, took the tool 30 seconds to generate but prospect thinks it took an hour. His cold outreach response rate went from 2% to 14% and it became his whole growth engine. The audit doesn't fix anything. It reveals what's broken. The paid product fixes it. These are also the fastest to build…. you're not building features, you're building a report.

Bucket two…. clean one room. You give full access to the real product but limit the USES not just the time. This matters a lot. A 14 day trial creates a countdown and pressure. A usage limit creates a habit. "First 10 reports free" beats "free for 14 days" because the person who runs 10 reports has built your product into their workflow. When they hit the wall they're not evaluating anymore…. they're already dependent. Implementation wise this is usually a pricing page change and a counter, not a rebuild. It works best when your SaaS solves a recurring problem.

Bucket three…. hand them step one. If getting the outcome takes 5 steps, give away step one completely free and genuinely good. A founder doing financial planning software could give away the budgeting template that actually works. It's real value. But doing step one manually reveals exactly how much time steps two through five will eat…. and your product does all 5 automatically. The free step sells the automation.

3 rules that decide whether your tool prints leads or collects dust.

Rule 1. It has to be good enough that you COULD charge for it. If your free tool is mediocre they don't think "imagine how good the paid stuff is." They think "this company makes mediocre stuff." The carpet cleaner's free room has to be SPOTLESS. A half cleaned room doesn't sell the house, rather it sells the competitor.

Rule 2. The name matters more than the tool. David Ogilvy said when you've written your headline you've spent 80 cents of your dollar. The SEO founder I mentioned…. his tool flopped for 2 months as "Free SEO Analyzer." We changed nothing except the name. We just changed the name to "Ranking Gap Report" and suddenly the same tool was converting. People don't want an analyzer but they want to know the gap between them and the guy outranking them. Test the name before you build anything. Two fake landing pages and 50 bucks of ads will tell you which tool to build before a single line of code gets written. I make founders do this now. It has killed more bad ideas than any amount of my advice ever did.

Rule 3. Make the next step stupid obvious. The tool runs, shows the result, and right there…. "want us to fix this for you?" One click. Most founders bury the upgrade path or worse, don't have one, because asking feels salesy. The carpet cleaner doesn't clean the free room and leave without a card. The entire point of the free room is the quote for the house.

Do this today. Write down the five problems your customer has to deal with BEFORE your product becomes the obvious answer. Choose the narrowest one you can solve completely with something that takes days to build, not months…. a “show them the dirt”  tool is genuinely a 1 to 2 week build for any competent dev, there's no excuse to sit on this for a quarter. Give it a name that says the outcome, not the category. Your customer will like "Churn Leak Finder" more than "Free Analytics Tool" every single time.

Traffic was never your problem. Lots of people walk through your house all day. They just can't see the dirt yet.

 

Most SaaS founders I talk to assume their posts get removed because they were too promotional. So they sand down the pitch, make it vaguer, and repost. Same outcome. What I've started to think is that the removal trigger isn't the content itself, it's the mismatch between what the community expects from a post and what you're actually doing there. A subreddit built around practitioners sharing war stories will kill a post that reads like a distribution play even if there's zero mention of a product.

I ran a rough audit across about 40 posts spread over three months, different communities, different framing styles. The posts that survived longest weren't the ones with the most neutral language. They were the ones where the community's own jargon showed up naturally, where the post asked something the regulars would actually argue about. That's a different variable than most removal postmortems focus on. Everyone talks about timing and karma thresholds. Nobody talks about whether your framing matches what the community rewards.

The B2B angle makes this worse because the communities worth posting in for B2B distribution are usually the ones with the highest standards for what counts as genuine participation. You can't fake your way into a subreddit full of operators who've seen every growth hack play out. They pattern-match faster than any mod filter does.

Curious whether anyone else has mapped this at the community level rather than the post level. Like, do you actually track which subreddits have a predictable removal logic versus which ones feel random? Because right now most of the advice out there treats every community as roughly the same problem with different rules, and I don't think that's true.

i’ve been doing cold outreach for b2b saas for a bit now and i’m still kind of stuck in that phase where it *kind of works*, but not in any predictable way. i’m at 2000+ emails sent so far. a few replies here and there, but nothing consistent enough where i’d say “ok this is a system that works”. what’s been messing with my head a bit is that i kept overthinking it early on tooling, setup, deliverability, etc. i was convinced i was missing something technical. but honestly the only noticeable shift i’ve seen so far was just cutting the emails down and making them way more direct. no fluff, no long intro, just straight to the point.

even then though, it’s not like it suddenly “clicked”.

for people who’ve actually gotten cold email to a point where it reliably brings in replies/leads in b2b saas:

what actually changed things for you?

was it:

• targeting / list quality (like *really* fixing ICP, not just “better lists”)
• personalization (light touch vs deep research)
• offer / positioning itself
• subject lines
• sending setup / deliverability (warming, domains, tools etc.)
• or something else that only made sense after you scaled it a bit?

i feel like there’s a lot of advice out there but most of it doesn’t really show what the actual inflection point was when things started working

I thought the biggest challenges when going to china would be localization, payment integration, and making sure the infrastructure could handle users in another region.

The more I've looked into it, the more I've realized China is an entirely different digital ecosystem.

Every topic seems to lead to something new. I've been reading about WeChat Official Accounts, Mini Programs, ICP filings, local cloud providers, app distribution, data compliance, and how websites or APIs that work perfectly well elsewhere can behave very differently for users in mainland China.

Also the customer journey seems different. In most markets, customers move between websites, email, and mobile apps. In China, it seems like a large part of that experience can happen inside WeChat, which changes how you think about onboarding, customer communication, and product design.

Normally we'd focus on CDNs, caching, and latency optimization, but for China there are additional considerations around hosting location, DNS behavior, compliance, and network performance that seem to influence architectural decisions from the beginning.

separating current best practices from outdated advice is also challenging. Some resources suggest you need to redesign everything, while others say a few well-planned changes are enough. Since a lot of the information online is several years old, it's not always clear what companies launching today are actually doing.

We're still in the research phase, but it's been a fascinating process. Preparing a B2B SaaS for China feels much less like another international expansion and much more like learning how to build for a completely different digital ecosystem

Tried Lovable last week for a small client portal. Demo out in an afternoon, first build looked solid.

needed two user types with different permissions, plus a database where each person only sees their own stuff. that is where I stopped trusting the demo and started testing what the app actually returned, not just what the screen showed.

I'm non-technical, so hand-wiring Supabase is rough. not impossible, just the kind of rough where one wrong assumption turns into a data leak later.

ive been looking at Enter because the docs talk about auth, database, functions, source export, and other post-demo pieces sitting closer to the builder. not calling it solved. i mostly want to see whether the user-data safety checks are easier to inspect before I ship anything.

don't have a week to hand-wire Supabase from scratch. if you actually shipped this on an AI builder, what was the path?

There's a design pattern on SaaS pricing pages that I find consistently correlates with lower self-serve conversion, and I want to describe it specifically because I think the intention behind it is usually good.

The pattern: comprehensive feature comparison tables — typically 30-50 rows comparing all plan tiers across every capability.

The intention: signal completeness, justify the price difference between tiers, and give serious buyers the information they need to make a confident decision.

The behavioral problem: on a self-serve pricing page, each row in that table is an additional micro-decision for the buyer. "Does my team need this? Would we use that? Is this row worth the price differential?" Decision fatigue research shows that decision quality degrades as decision count increases. By row 35-40, the buyer's cognitive resources are significantly depleted — and the easiest decision available to them is to close the tab.

Here's the nuance that I think explains why teams keep building this way:

The comprehensive feature table genuinely serves a purpose in enterprise sales. When a champion needs to build an internal business case and justify the purchase to finance or procurement, that depth is useful. It provides a defensible rationale for the investment.

But enterprise sales has a human — an AE, a SE, a customer success person — to guide the buyer through that complexity. Self-serve pricing doesn't. The page has to do that work alone, and a page can't adapt to what a specific buyer needs to know right now.

Linear's pricing approach is worth studying as a contrast — not because it's minimal for aesthetic reasons, but because it's designed to function as a decision closer rather than a decision expander. Each tier has a clear "this is for teams that..." descriptor. The implicit message is: we've already done the evaluation work. You just need to confirm which category you fall into.

The diagnostic I'd suggest: can a first-time visitor identify their correct plan in 60 seconds without consulting the feature comparison? If not, the pricing page is asking for more cognitive work than self-serve buyers will typically invest.

Curious what others have found correlates most with self-serve conversion on pricing pages — especially at the enterprise vs. SMB tier boundary.

Curious how other reps think about this, because I don’t think there’s a universal rule.

Not asking for “the right number”, I know that’s subjective and depends on deal size, vertical, timing, etc. What I’m actually curious about is the feeling. At what point do YOU personally start to feel like you’re the one being weird about it, not because of some playbook rule.

Is it a specific touch number? A tone shift in your own messages? The moment you start over-explaining why you’re reaching out again? Genuinely curious how other people notice that line in themselves.

Personally: I have it rather quickly. Don’t want it? Then fuck off. But I don’t act like this because no deal would ever get done.

Heard this one a lot when we started. Don't target small and medium businesses in India. Long sales cycles, low willingness to pay, high churn. Go enterprise or go abroad.

We ignored it partly because our product is built for a segment that's mostly SMBs.

What we found is the advice is half right. The willingness to pay part is real. Price sensitivity is intense, conversations go in circles, and getting to a yes takes way longer than it should for the contract size involved.

But the "go enterprise" advice assumes you can get into enterprise. For a early stage startup with no brand name, no case studies, no existing network in that world, enterprise is its own nightmare. Procurement, legal, security reviews, 6 month sales cycles. At least SMBs pick up the phone.

The honest answer might be that neither is great at the start and it depends entirely on whether your product solves something urgent enough that someone will pay despite the friction.

Curious what others have found. Is the SMB advice outdated or still holds? And for people who made the switch to mid-market or enterprise in India, how did you actually get that first foot in the door?

everyone is slapping the word "agent" on their landing page to boost conversion. but if i have to read a 12-step onboarding doc and manually guide the AI through 4 different tabs just to get it to do the thing, it's not an agent. it's an intern with a login screen that needs constant micromanagement.

an actual agent should just do the work while you focus on the decision making. feels like we're in this weird phase where any feature that takes text input is suddenly an "autonomous agent". curious if anyone has actually found one recently that genuinely works in the background without needing a babysitter?

We're building a B2B fintech platform and I figured choosing a payroll provider would be one of the easier decisions we'd make

It's turned into weeks of conversations about customer experience, compliance, support and where we want the product to be a few years from now

It feels like this decision is about a lot more than just plugging in an API 

Has anyone else gone through this? What ended up being the deciding factor?

Your content gets views. Your LinkedIn posts land. People say "this is exactly our problem" in the comments. Then... nothing. No booked call. No reply to the follow-up.

This is the gap most SaaS founders misdiagnose. They think they need more visibility, so they post more, run more ads, chase more impressions. But the problem isn't that people don't know you exist, it's that knowing isn't the same as acting.

Why awareness stalls before it becomes a demo:

The ask comes too early or too late. Pitch a demo before someone's felt the pain clearly articulated, and it feels like a sales push. Wait too long after they've engaged, and the moment passes, they've moved on to the next thing in their feed.

There's no low-friction next step. "Book a call" is a big ask from someone who just liked a post. Without a smaller, specific entry point, a quick audit, a relevant resource, a direct question interest has nowhere to go.

Follow up treats everyone the same. A like, a comment, and a DM are three different signals of intent. Sending the same generic outreach to all of them wastes the people who were genuinely close to converting.

What closes the gap:

Engagement needs a designed next step; not a hope that someone clicks "Book a Demo" on their own. Match your follow up to the signal strength. And make the first ask small enough that saying yes costs nothing.

Visibility gets you noticed. Intentional follow-through gets you booked.

i’m trying to keep outbound simple but it keeps turning into a mess.

one tool for finding leads, another for verifying emails, another for sending, another crm, then sheets in the middle because nothing fully syncs.

at this stage i’m not even sure the problem is “better copy”. feels more like too much ops for a small team.

how are other small saas teams keeping outbound lightweight?

Hi All,

I've been working on a template to help bootstrap a B2B saas products.

Does that sound useful?

I always have a bunch of requests from friends, family and other people for ideas and requests for some B2B app, but there is always a basic feature set that takes ages to put together before you can start working on the actual "app" features.

Things like login, authentication, invitations, installing initial frameworks and packages.

So I'm setting up a template using my favorite current stack (typescript/prisma/postgres/nextjs/shadcn/better-auth) to give you all that out the box, with a nice design pattern setup for scaling the app nicely over time (good separation of concerns e.t.c)

It will come with a basic Admin Dashboard for backoffice type tasks, and the Customer Dashboard as the main app interface. Both super minimal with just the basic auth and adding user and organization flows.

Am setting up it to scale nicely for multi-tenancy also, so imagine not just supporting your typical B2B saas setup, with the Admin and Customer portals, but making it easy to support multiple tenant types also. E.g for an Uber app, you need to support Drivers, Users, Backoffice staff, i.e multiple tenant types.

Does this sounds like it would be useful?

Its still in progress and planning to open source it once am done.

What’s the hardest part after launching a product?”
“Where do you discover new software?”
“Do you feel Product Hunt actually brings long-term users?”

When I started building my SaaS, I thought the hardest part would be writing the product.

It wasn't.

The hardest part was getting people to know it existed.

I tried LinkedIn.

Cold email.

Scraping.

Newsletters.

Founder branding.

Every week I added another tool.

Eventually my "growth stack" looked something like this:

• one tool for email
• another for verification
• another for LinkedIn
• another for analytics
• random spreadsheets everywhere

None of them actually talked to each other.

I wasn't building my product anymore.

I was managing outbound.

That realization completely changed what we're building.

Instead of adding another AI feature, we started asking:

"What if outbound itself was the product?"

One system.

Email.

LinkedIn.

Infrastructure.

Execution.

Not five subscriptions duct-taped together.

Still early.

Still figuring things out.

But it's funny how the product you end up building is usually the one you desperately needed yourself.