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.
Great breakdown. What feedback have you had from early users?
The biggest theme so far: people don't want to stitch Clerk + Stripe + a workflow engine together themselves.
This is useful. How are you finding your first users so far?
Mostly through building in public here, on X, and on Reddit, plus direct conversations with founders.
Nice progress. What is the next thing you are focusing on?
Launch day first, then tightening activation so new devs get to a working app faster.
What made you pick this stack over the alternatives?
We build our own products on React/Next.js, so we built the SDK for the stack we actually use every day.
Makes sense. Are you planning to charge for it, or keep it free for now?
Paid from day one, no free plan. BYO Stripe with a 0% platform fee on top.
Good write-up. What would you do differently if you started again?
I'd put it in front of outside developers much earlier instead of only dogfooding it on our own products.
Great breakdown. What feedback have you had from early users?
Most useful feedback has been around onboarding
Makes sense. Are you planning to charge for it, or keep it free for now?
Charging from day one. If it saves you weeks of backend work, it should be worth paying for.
Interesting approach. What was the hardest part to get right?
Billing and usage metering. That's where bugs quietly cost money, so it had to be right.
Appreciate the honesty here, most people only share the wins.
Appreciate that. The misses teach more than the wins.
Really relatable. How much time do you put into this each week?
It's the main thing I work on.
Helpful post. How did you get your first bit of traction?
Our first external paying customer. Before that, it was only our own 6 products running on it.
Solid lesson. Which channel has worked best for you so far?
Too early to call a clear winner.
Really relatable. How much time do you put into this each week?
Most of the week, honestly. It's full-time.
This is useful. How are you finding your first users so far?
Mostly through building in public here, on X, and on Reddit, plus direct conversations with founders.
What made you pick this stack over the alternatives?
We started by solving our own problem. Our products are all Next.js, so that's where we started.
Interesting. How are you measuring whether it is working?
Whether new devs get from signup to a working app. That's the number I watch most closely.
Interesting. How are you measuring whether it is working?
Activation, more than signups. Did they actually ship something with it?
This resonates a lot — how long did it take before you saw any real signal on it?
Honestly, it took a while. The first real signal was an external team paying for it, not just us using it internally.
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.
Agreed, time-to-first-working-thing says a lot. That's why it's a single npm install. Curious: what's the longest setup you've sat through before giving up on an SDK?
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.
Novruz, this is exactly the kind of comment I was hoping for. Checking the pricing page and those hydration errors right now. Thank you for going through it like a real buyer would. If you want to poke at sign-up and billing from the inside, happy to set you up with an account.
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.
Dogfooding is the big one for me too. All 6 of our own live products run on BuildBase, so if something breaks, we feel it first. Recent commits and issue response time are fair game to judge us on.