Product Hunt gave me almost no traffic, so I built a free tool around the problem

So far, Indie Hackers has produced the most meaningful conversations. X and Reddit are still experiments for me, so I’m focusing on where I can have genuine technical discussions rather than just chasing impressions.

Mainly because I wanted a stack that gives me strong primitives without hiding the important parts. Next.js gives me the app layer, Supabase/Postgres gives me database + auth + RLS, and Stripe handles billing. It keeps the core infrastructure inspectable and easy to extend.

Honestly, distribution has been the biggest challenge. The product itself is working, but getting it in front of the right developers is much harder than building it. That's actually what led me to build the free production-readiness check as an entry point.

Mostly through technical communities and content so far. I’m focusing on showing the actual problems the product solves rather than pushing the product directly. I’ve also started using the free readiness check as an entry point: andrady.co/check

Honestly, I was tired of rebuilding the same SaaS infrastructure every time — auth, multi-tenancy, RBAC, RLS, billing, API keys, audit logs, etc. I figured other developers were probably wasting the same time, so I built the foundation I wished I had.

Yeah, I figured the failures are probably more useful to share than pretending everything went perfectly. The biggest lesson so far has been that building the product and getting the right people to see it are two very different problems.

Yes, but I'd keep the scope tight. I'd still choose the stack because it lets you move quickly without abstracting away the database and security layer. The important part is understanding what you're shipping rather than treating the stack as a magic shortcut.

Mostly positive on the technical side so far. The biggest feedback has been that having auth, multi-tenancy, RLS, RBAC and billing already wired together saves a lot of setup time. I'm still early enough that I'm actively looking for more developers to stress-test it.

Honestly, I’m still waiting for the first real sales result. The product was ready before launch, but getting it in front of the right developers has been the harder part. I’m treating distribution as the next problem to solve rather than pretending I’ve figured it out already.

Thanks. I figured sharing the actual process would be more useful than pretending everything went perfectly. I'm learning a lot from the gap between building something technically solid and actually getting it in front of the right people.

So far, technical communities have been the most useful. Indie Hackers has given me the most meaningful conversations, while I'm still testing X and Reddit. I'm realizing the quality of the audience matters much more than raw traffic.

Yes, but I'd keep the approach focused. Build something you genuinely understand, validate the problem early, and don't assume that shipping automatically creates distribution. I'd spend as much time figuring out how to reach the right users as building the product.

Appreciate it. Hope it’s useful when you get around to it.

Still waiting on the first sale, honestly. The biggest result so far has been getting real technical conversations and learning which problems people actually care about. I'm treating that as validation before trying to scale distribution.

The readiness check is staying free. The B2B SaaS OS is the paid product at $249 one-time. The idea is to make the free check genuinely useful on its own, then let people who need the actual infrastructure foundation discover the paid product naturally.

Yes, but I’d keep it focused. Build something you genuinely understand, validate the problem early, and treat distribution as part of the product—not something you figure out after shipping.

That's a really good distinction. I was treating tenant isolation mostly around request-time access, but background jobs definitely create another boundary where the original tenant context can disappear. I'll add that as a separate check/test case.

So far, Indie Hackers has produced the most meaningful conversations. X and Reddit are still experiments, so I'm focusing on channels where I can have genuine technical discussions rather than just chasing impressions.

This is exactly the kind of feedback I was hoping to get. The background-job tenant boundary is already something I’m going to split out, and I’ll add connection pooling and domain authentication to the next version of the checklist. Appreciate the detailed suggestions.

So far, Indie Hackers has produced the most meaningful conversations. X and Reddit are still experiments, so I'm focusing on channels where I can have genuine technical discussions rather than just chasing impressions.

That’s a really good point. Background jobs are easy to overlook because the happy path works while failures, retries and ordering issues stay invisible until you have real usage. I’m going to add observability around async workflows to the checklist. And right now I’m treating the free check as both a lead generator and a way to learn what developers actually worry about.

Exactly. That’s what I want to learn now. I’m tracking which parts of the check people engage with and whether completing it leads to interest in the OS. If a specific failure point consistently gets people curious, that’s probably where I should focus more of the content.

I’d look for behavior beyond just completing the check: sharing the result, clicking through to the OS, checking the demo, visiting the product/pricing page more than once, or asking technical questions about implementation. A completed check tells me there’s interest; those actions would tell me whether there’s potential buying intent.

That’s great to hear. I think the bigger lesson for me is that the outcome depends heavily on having an audience or distribution going into the launch. I had almost no existing audience, so I’m experimenting with building that distribution before relying on another launch.

That's a really good distinction. I don't think my current auditability check cleanly covers the “action succeeded or outcome is unknown” state. I'd treat that as a separate reliability check rather than pretending idempotency solves it. The confirm-before-execute case you described is especially interesting because blindly retrying can itself be unsafe.

Right now I’m focusing on distribution and learning from the readiness check. I want to get enough developers through it to see which problems resonate most and whether that actually translates into interest in the $249 OS before I build anything else.

Definitely. I expected the hardest part to be building the product, but the bigger surprise has been how different distribution is from development. I also didn't expect the technical conversations around the readiness check to be this useful for discovering problems I hadn't considered.

The readiness check will stay free. The B2B SaaS OS is the paid product at $249 one-time. I want the free tool to stand on its own as something genuinely useful, with the paid product being the next step for people who need the actual infrastructure.

Pretty much every day right now. I split the time between building, talking to developers, and distribution. Lately I've been deliberately shifting more time toward distribution because I've learned that shipping the product is only half the job.

That’s a really good point about discovery vs. conversion. I’m seeing the same thing already — the checker needs to be distributed through the technical communities where the problem is being discussed. I don’t have enough completed checks yet to say which item has the highest fail rate, but Stripe webhook idempotency is definitely one I want to turn into a standalone technical post. I’ll track the failure distribution as more people use it.

That's a good distinction. I don't want the checker to become a generic checklist either. I'm going to track which individual checks create the most drop-off, failures, and clicks toward the OS. If one consistently gets developers digging deeper, that's probably the problem worth building the content around.

Next I’m focusing on distribution and learning from the checker. I want to get enough developers using it to see which checks actually resonate, then turn the strongest findings into standalone technical content rather than just adding more product features.