1
22 Comments

Launching on Product Hunt tomorrow. What's the one thing you check before trusting a new SDK?

We launch BuildBase tomorrow (Sep 25, 12:01 AM PT). It's a SaaS backend SDK for React/Next.js: auth, billing, workspaces, roles, workflows, email and the rest, 20 modules in one install.

Instead of pitching it, I want to ask the thing I keep wondering about.

When you land on a new SDK's page, what's the first thing you look for before you'd build on it? For me it's usually the docs and whether I can leave with my data. But I've heard people say it's the changelog, the GitHub issue response times, or just whether a real human answers support.

What's yours? I'd rather fix that thing before tomorrow than after.

on September 24, 2026
  1. 1

    Great breakdown. What feedback have you had from early users?

  2. 1

    This is useful. How are you finding your first users so far?

  3. 1

    Nice progress. What is the next thing you are focusing on?

  4. 1

    What made you pick this stack over the alternatives?

  5. 1

    Makes sense. Are you planning to charge for it, or keep it free for now?

  6. 1

    Good write-up. What would you do differently if you started again?

  7. 1

    Great breakdown. What feedback have you had from early users?

  8. 1

    Makes sense. Are you planning to charge for it, or keep it free for now?

  9. 1

    Interesting approach. What was the hardest part to get right?

  10. 1

    Appreciate the honesty here, most people only share the wins.

  11. 1

    Really relatable. How much time do you put into this each week?

  12. 1

    Helpful post. How did you get your first bit of traction?

  13. 1

    Solid lesson. Which channel has worked best for you so far?

  14. 1

    Really relatable. How much time do you put into this each week?

  15. 1

    This is useful. How are you finding your first users so far?

  16. 1

    What made you pick this stack over the alternatives?

  17. 1

    Interesting. How are you measuring whether it is working?

  18. 1

    Interesting. How are you measuring whether it is working?

  19. 1

    This resonates a lot — how long did it take before you saw any real signal on it?

  20. 1

    For me, the first thing I’d check is how easy it is to actually get started. Good docs, a working demo, and a clear setup process tell me a lot before I commit to an SDK.

  21. 1

    Hi Dharmendra, I'm Novruz, a QA engineer. I test web products before launch, and since you asked what to fix before tomorrow rather than after, I went through BuildBase the way a developer comparing it with Clerk would.

    The one I'd fix tonight is the Pricing page. The nav link opens a page titled "Plans from $49/mo", but on my visit it showed the heading, the Stripe badge and the FAQ, and no plan cards at all, in the served HTML and after load. The $49 / $99 / $199 cards only live on the homepage. The console there throws two React hydration errors (#425 and #422), a common reason a block goes missing. On launch day Pricing is usually the second click.

    What I can't check from outside is the part your question is really about: sign-up, the billing module and data export inside the console.

    Thanks for asking before launch instead of after, and good luck tomorrow.

  22. 1

    Docs quality + active maintenance (recent commits, issue response time). If the README hasn't been updated in 6 months, I assume it's abandoned. Also check if they dogfood their own SDK — nothing beats seeing the team use it in their own product.