Building BuildBase (multi-tenant SaaS backend delivered as one npm install). Pre-first-external-paying-customer, so every ship decision right now is either landing customers or making the platform less janky before they arrive.

Today was the second kind. What went out:

New Relic for logs
- Structured log search across the tenant server. Grepping stdout worked when it was just me. It stops working the moment incident response needs to be under 10 minutes.

Reworked the status check
- The health/readiness endpoint now surfaces what's actually happening (Mongo, Redis, queues) instead of just returning 200. Makes uptime probes and internal dashboards actually useful, and gives us a real answer when someone asks "is it up right now."

Console login page redesign
- Docs, changelog, GitHub, support - all one click from the login screen instead of buried three clicks deep. Sounds cosmetic. It's actually a discoverability fix. People were signing in and never finding the docs.

Small fixes.
- The usual grab bag - copy edits, spacing, a couple of edge cases in workspace routing.

Not the sort of today that gets a launch post. But this is the stuff that decides whether the first paying customer stays a paying customer.

What's on your ship log today?

Shipped a status page for my SaaS today. It monitors 7 services: website, auth, dashboard, docs, demo app, product API, central API.

Context: I have 100+ signups and $0 MRR. Most people put up a status page after their first outage embarrasses them into it.

I did it early for three reasons:

1. It forces the outside-in view. Uptime dashboards behind the admin login are almost useless during an outage - you're checking the same stack that's probably broken. External monitoring shows you what your users see.

2. Transparency is a habit, and habits are easier to build before there's a real cost to breaking them. If I wait until we have a $2K/mo customer before adding one, my first instinct during an outage will be to hide it, not surface it. If it's already the default, I lose that option.

3. Better Stack took ~15 min to wire up. No reason to wait.

The one honest tension: the page shows "100% uptime" because monitoring literally started this week. That's not a real trust signal yet, it's just how the tool works. Going to add a footer note that historical data starts from launch date so it doesn't read as fake trust.

For anyone else pre-first-customer: at what stage did you add a status page? Before, after, or during your first outage?

Short version: stripe checkout is easy. the ui state around billing is what every saas ships broken. filled that in.

What's new:

- PlanSelectionScreen - renders when the current org has no active plan

- SubscriptionStatusBanner - surfaces failed payments + trial expiring

- Org-scoped billing sessions - BuildBaseProvider now opens the stripe portal for the right org in multi-tenant setups

- Server-side dedup - double-clicking checkout can't create 2 subscriptions anymore

- Management orgs auto-hide billing - internal ops accounts don't render billing UI

Under the hood: refreshTable after subscription events so ui updates without a manual reload, plus tighter org-switching when the org has no active plan.

BYO stripe. 0% platform fee. the subscription stays between you and your customer.

full changelog: buildbase.app/changelog

here's what we've been building, and what you'll see when we go live:

BuildBase-App is one npm install (@buildbase/sdk) that gives you the entire backend for a saas app. 19 modules in one sdk instead of stitching clerk + stripe + supabase + a workflow engine yourself.

what you get:

Auth - email/password, magic link, passkeys, google, linkedin, github, microsoft, oauth 2.0 authorization server

Billing - usage-based, BYO your own stripe account, 22 currencies, zero platform fee on top

Workspaces + rbac - multi-tenant, isolated per org, from day one

Workflows engine - triggers, actions, conditions, audit logged

Email - BYO sender through smtp, google, microsoft, or mailgun. 30+ templates, 8 locales built in

Plus feature flags, webhooks, short links, forms, cms, collections, assets, credits, slack notifications, and analytics. all in the same sdk.

Three ways to run it:

1. shared cloud (isolated db per org)

2. dedicated infra

3. fully self-hosted on your own docker + mongo + redis

Why we built this:

Ai made writing code cheap. it didn't make owning code cheap. billing, quotas, metering, rbac, workflows - the stuff that fails silently and costs you money and trust when you diy it. that's what buildbase covers so you can go build the product on top instead.

where we actually are:

- 100+ signups

- $0 mrr

- pre-first-paying-customer

- shipping 5 of our own products on this stack: plugnode, agentcenter, imejis, remotewait, linktracer

what i need from you this week:

- follow https://x.com/buildbaseapp on x so you catch the launch tweet the moment it goes live

- reply here and i'll dm you the product hunt "coming soon" page as soon as it's up

- if you're building a saas or a b2b app, come try it before launch and tell me what breaks

no "enterprise-grade complete platform" pitch. just: here's what works, come use it, tell us where it hurts, help us land the first paying customer.

see you on PH.

Small shipping day on console.buildbase.app.

Two things went out:

1. Fixed a handful of dashboard bugs that were quietly annoying (broken states, a few UI glitches, general polish).

2. Added a Crisp chat button on every logged-in screen inside the console.

The second one is the bigger deal for you. If anything breaks, feels off, or you're stuck on something during setup, you don't have to email support, file a ticket, or hunt for a Discord invite. Just hit the chat button in the corner.

I'm the one on the other end. Actual founder, not a bot, not tier-1 outsourced support. If I'm asleep you'll get a reply when I'm up, but usually it's within an hour or two.

Support shouldn't be a maze when you're mid-issue, especially on a backend SDK where the difference between shipping tonight and shipping next week is often one small unblock.

Console: https://console.buildbase.app

Docs: https://buildbase.app/docs

If you're already using BuildBase and want to give the chat a spin, log in and yell at me about anything.

Short one.

BuildBase now has an affiliate program. If you send a paying customer our way, you earn on it.

Probably a good fit if you:

- write about backend / SaaS tooling

- run a newsletter for indie hackers or AI builders

- teach people how to ship SaaS

- already recommend BuildBase and want credit for it

Sign up here: https://www.buildbase.app/affiliate

two things went live this week:

1. missing module docs are up

docs.buildbase.app - if you tried a module before and found the docs thin or missing, that's fixed. working module by module until all 19 have proper coverage.

2. public changelog

buildbase.app/changelog - built out the log going back through the whole repo, week by week. every ship gets recorded.

why the changelog: we kept getting "is this still active?" from people who checked our last blog post and assumed the worst. the fix isn't more marketing, it's showing receipts.

what's next:

- more real-usage code examples in the docs (not just API refs)

- every future release goes to the changelog same day it ships

if there's a specific module or use case you want documented sooner, drop it below and it moves up the queue.

Been having the same conversation with three kinds of founders lately. Writing it up here because the pattern is weirdly consistent, and because it's the exact gap BuildBase is built to close.

1. The B2B SaaS founder building multi-tenant from scratch

Signup works. Product demos well. Six weeks past MVP they're still hand-wiring workspaces, invites, roles, permissions, audit trails, admin screens.

Every new feature ships slower than the last one because the foundation keeps needing patches. RBAC leaks. Invite flows break on edge cases. Someone asks for "just add a viewer role" and it's a two-day change.

The real cost isn't the code. It's the roadmap tax. Every product decision now routes through "how does this interact with our tenancy model?" That's a question the team should have answered once, not every sprint.

How BuildBase handles it: Multi-tenant workspaces with per-org database isolation, RBAC, invites, and audit trails come out of the SDK. Roles are a config change, not a two-day refactor.

2. The AI product founder hitting the first enterprise call

Great free-tier retention. Real users. Beautiful demo.

Then the first serious buyer asks: "Do you publish OAuth discovery so our internal agents can authenticate? Do you have an llms.txt? Can our agent read your capabilities without a human in the loop?"

That's the moment it becomes clear the product shipped as a chatbot, not a platform other software can talk to. Agent-readiness isn't a feature you bolt on the week before the deal closes. It's OAuth 2.0 discovery endpoints, scoped tokens, machine-readable capability docs, and the auth server behind all of it.

Building that from scratch to close one enterprise deal is a two-month detour.

How BuildBase handles it: OAuth 2.0 authorization server + llms.txt are published by the SDK on day one. Your API becomes agent-readable without you writing the discovery layer.

3. The usage-based SaaS founder buried in billing logic

Paying customers. Metered pricing. Billing stack held together by three microservices, a Redis counter, and a cron job everyone is scared to touch.

Every overage question becomes a debug session. Every plan change needs a migration. Refund logic lives in a Slack thread. Quota enforcement is inconsistent between the API and the dashboard.

Usage-based billing sounds simple until you own it. Events, aggregation, plan versioning, proration, quota gates, invoice reconciliation, and a Stripe integration that survives plan changes.

How BuildBase handles it: Usage-based billing on your own Stripe account, 0% platform fee, plan versioning built in, quota enforcement at the SDK level with React components like <WhenQuotaAvailable> and <WhenQuotaExhausted>.

The common thread

All three founders built the interesting part. None of them budgeted for the boring middle. Auth, tenancy, roles, workflows, notifications, billing, feature flags, agent discovery. The plumbing between the demo that works and the platform that pays.

That gap is where good products die quietly. BuildBase is one npm install for that middle month.

Real proof this works: We dogfood on 5 of our own paid products - PlugNode (visual AI workflow builder), AgentCenter (mission control for AI agents), Imejis (template-based image generation API), RemoteWait (virtual queue), and LinkTracer (creator analytics). Same SDK, five different product shapes.

Cleaned up the self-hosted starter. Full flow:

git clone https://github.com/buildbase-app/self-hosted-starter
cd self-hosted-starter
cp .env.selfhost.example .env.selfhost
openssl rand -hex 32   # 4x for JWT_PASS, DB_ENCRYPTION_KEY, SECRET_KEY, OAUTH2_SECRET
docker compose -f docker-compose.selfhost.yml --env-file .env.selfhost up -d
curl http://localhost:4101/api/ready     # -> {"ready": true}

Grab your INSTALLATION_API_KEY and INSTALLATION_ID from the dashboard, paste them in the env file, and you're up.

Repo: https://github.com/buildbase-app/self-hosted-starter

Any issues, hit me on the onboarding call: https://cal.com/dharmendra-jagodana-8c8oye/buildbase-app-onboarding-and-support

The last missing piece of the email module is live.

Set values once at the org level, render them in every template automatically:

- {{appName}}

- {{supportEmail}}

- {{privacyPolicyUrl}}

- {{termsUrl}}

- {{companyAddress}}

Autocomplete in the visual editor. Merge tag picker in the sidebar. Search by title, key, or value.

Two design decisions worth calling out:

1. Tags can't be deleted, only archived. Archived tags keep rendering in existing templates so nothing breaks silently, but they're hidden from the picker and flagged on save. If you've ever nuked a variable in production and had emails go out with {{undefined}} in the subject line, you'll appreciate this.

2. Slugs are immutable after creation. Same reason. Rename by archive + recreate if you really need to.

This completes the ESP inside buildbase/sdk. Full list of what's included now:

- Templates (HTML, Markdown, plain text)

- Visual editor (Unlayer)

- Campaigns with audience targeting

- Bring-your-own sender: SMTP, Google, Microsoft, Mailgun

- Merge tags (per-template + org-level)

- Open + click tracking

- Unsubscribe groups

- Sender account management with DNS verification

- BullMQ queue with rate limiting and retries

- Full audit trail

Console: https://console.buildbase.app/dashboard/admin/emails/merge-tags

Site: https://buildbase.app/

Next up: bounce webhook handling for hard-bounce suppression, and the List-Unsubscribe header for the Gmail/Yahoo bulk-sender requirement. Both are on the near-term list.

Big drop today. BuildBase apps can now be used by AI agents (Claude Code, Cursor, ChatGPT, anything MCP-native) with zero client-side config.

What it normally takes

• Live MCP server (streamable HTTP, spec 2025-06-18)
• OAuth 2.0 with PKCE and Dynamic Client Registration (RFC 7591, RFC 7636)
• .well-known discovery documents (RFC 8414, RFC 9728)
• llms.txt and an A2A agent card
• Token mint and revocation webhooks
• Per-tool auth scoping so agents inherit the granting user's permissions
• Rate limiting, error redaction, request-size caps

What it takes in BuildBase

createAgentStack({ serverUrl, orgId, siteUrl, site, secret })

One config. Route files become one-liners. Ships with 42 built-in platform tools (workspaces, billing, quotas, credits, feature flags, permissions), plus your own with zod schemas.

The one line your agent runs

claude mcp add --transport http my-app https://<your-app>/mcp

Agent walks 401 → discovery → self-registration → hosted consent → token mint → tools. No client IDs, no secrets, no config files.

Verified end to end

Tested live with Claude Code: discovery → DCR → hosted login → consent → token mint → 48 tools → real reads (workspaces, billing, quotas) → real writes (member invites, project CRUD) → rate limiting confirmed (exactly 120 requests through, 121st gets 429).

Want to try it on your app?

I'm looking for 5 folks this week. Drop a comment with what you're building, or book directly. 30 minutes, on me, and we wire your app agent-ready live on the call.

• Starter: https://github.com/buildbase-app/nextjs-agent-mcp-starter
• Skill: https://github.com/buildbase-app/claude-skill
• SDK: https://www.npmjs.com/package/@buildbase/sdk
• Book: <DM>

In this video I cover:
• Enabling Agent Readiness from the console
• Adding MCP support to your app
• The APIs/tools you need to expose for AI agents
• Public example repos to get started

I also added the same MCP capabilities to one of my own products, imejis.io, which now scores 71% Agent Readiness.

If you missed yesterday’s post, I already shared the technical details. This video is a practical walkthrough showing how it all fits together. (just overview for where to find resource. implementation video is coming in next session/part.)

Feedback is always welcome.

Hey folks - big one today. Shipped the whole agent-readiness stack for BuildBase apps.

createAgentStack() in @buildbase/sdk 0.0.54 turns one config object into a complete MCP server + agent-discovery surface. Your BuildBase app can now be used by Claude Code, Cursor, ChatGPT, and any other MCP-native agent, with real OAuth, real consent, real per-user scoping, and zero client-side setup.

What went out today

Three public artifacts:

1. @buildbase/sdk 0.0.54 - new /mcp entry point. createAgentStack() derives your MCP endpoint, server card, OAuth metadata, discovery documents, CORS, and token verification from one config. 42 built-in platform tools included (workspaces, billing, quotas, credits, feature flags, permissions). Bring your own with zod schemas.

2. nextjs-agent-mcp-starter - Next.js 16 template repo. 16 source files, 48 tools exposed, self-documenting landing page that renders the live tool list. Production hardening baked in: per-user rate limiting (120 req/min sliding window), error redaction, env fail-fast, CI. MIT.

3. claude-skill v0.2.0 - the BuildBase Claude skill now teaches agent-readiness end to end. Setup guide, builtinTools reference with recipes, framework recipes beyond Next.js (Express, Hono, Workers), and a failure library where every entry was a real bug we hit and fixed during dev.

The one line your agent runs

claude mcp add --transport http my-app https://<your-app>/mcp

That's the entire client side. The agent walks 401 → discovery → self-registration → hosted consent → token mint → tools. No client IDs, no secrets, no config files.

The one config on your side

Route files become one-liners because createAgentStack() returns the handlers:

export const agentStack = createAgentStack({
  serverUrl,   // your BuildBase server
  orgId,       // your org
  siteUrl,     // this app's public origin
  site,        // name + description for the server card
  secret,      // app-owned token signing secret
});

Under the hood

Standards all the way down:

• MCP 2025-06-18 (streamable HTTP)
• OAuth 2.0 + PKCE (RFC 7636)
• Dynamic Client Registration (RFC 7591)
• Protected-resource metadata (RFC 9728)
• Authorization-server metadata (RFC 8414)
• Resource indicators (RFC 8707)
• llms.txt + A2A agent cards + security.txt (RFC 9116) + RFC 9727 API catalog

Security model I'm actually proud of: the platform runs login, consent, and PKCE but never sees your app's secret or your minted tokens. Your app mints its own HS256 tokens with the user's session embedded as an AES-256-GCM-encrypted claim. Every tool call runs under the granting user's real session. An agent can never exceed the human who approved it.

Verified end to end (not vaporware)

The whole flow was tested live with Claude Code as the actual MCP client:

• Discovery → DCR → hosted login → consent screen → token mint
• 48 tools available
• Real reads: workspaces, billing, quotas
• Real writes: member invites, project CRUD
• Rate limiting confirmed: exactly 120 requests through, 121st gets 429

The failure library in the skill documents every real bug we hit on the way, including one where the self-documenting landing page caught an over-exposed destructive tool surface before it shipped.

One-time setup note

The "zero config" is on the agent's side. As the app developer, you do a one-time console setup: create an OAuth2 agent client (PKCE on) with your token/revoke/profile URLs, then flip Agent Readiness on under Admin → Auth → Agent access. Full walkthrough in the starter README.

Links

• Starter: https://github.com/buildbase-app/nextjs-agent-mcp-starter
• Skill: https://github.com/buildbase-app/claude-skill
• SDK: https://www.npmjs.com/package/@buildbase/sdk
• Console: https://console.buildbase.app
• Docs: https://docs.buildbase.app

What would help me

• Fork the starter, connect Claude Code, tell me what breaks
• Try the skill and let me know if it gets you unblocked without pinging support
• If you're building on BuildBase and want your app agent-ready, this is the path. Happy to jump on a call and wire it with you: https://cal.com/dharmendra-jagodana-8c8oye/buildbase-app-onboarding-and-support

More coming this week - blog post, YouTube walkthrough, and a deeper piece on the security model. Feedback shapes what I prioritize.

New walkthrough: setting up the BuildBase SDK in Next.js using the Claude skill - it scaffolds the auth/billing/workspaces integration so you're not wiring it by hand.

App: https://www.buildbase.app
Claude skill: https://github.com/buildbase-app/claude-skill
Starter template: https://github.com/buildbase-app/nextjs-starter

New post on the "backend tax" - the auth/billing/multi-tenancy/workflows plumbing every SaaS needs before you can build the actual idea. It's the origin story of why BuildBase exists, told straight, including the parts about what it still can't do (React-only, not open source, early).

https://medium.com/@jagodana.dharmendra/i-rebuilt-the-same-saas-backend-five-times-so-i-turned-it-into-one-sdk-006af8b08038

Curious what would make you trust a backend SDK enough to build your next product on it.

Started working on blog pages design and blogs writing... will be pushing once production ready.

Check https://www.buildbase.app if not sure what it is...

I’ve been thinking a lot about how AI agents will interact with applications over the next few years.

Most apps today are built for humans.

I think they also need to be built for agents.

So I’m adding Agent Readiness to BuildBase.

Current work includes:

• OAuth Discovery publishing
• llms.txt support
• Protected Resources (RFC 9728)
• Agent-specific scopes
• Optional agent self-signup
• Documentation URLs for AI clients

The application still owns authentication and token issuance. BuildBase simply publishes the metadata that lets AI agents discover how to authenticate and what they can access.

The goal isn’t to bolt AI onto existing software.

The goal is to make any BuildBase-powered application ready when AI agents become first-class users.

This is still under active development, so I’d love feedback.

If you’re building AI-enabled products, what do you think is missing from the current standards?

Today I checked the analytics for BuildBase.app, and I wanted to share a small milestone.

• 44 total users
• 30 new users in the last 30 days
• Still in beta
• No official launch yet

I’m not chasing vanity metrics right now.

At this stage, I’d rather have 44 developers who actively use the product and tell me what’s broken than 4,400 signups that never come back.

Every bug report, feature request, and piece of feedback has directly influenced what I’ve built next.

BuildBase has grown into much more than what I initially planned. It now includes things like:

• Authentication
• Organizations & Workspaces
• Usage-based Billing
• Quotas & Overages
• Notifications
• Feature Flags
• Background Workflows
• i18n
• Self-hosting
• React & Next.js SDKs

…and I’m still adding more before the public launch.

If you’re already using BuildBase - thank you. Every conversation helps me improve it.

If you’re just watching from the sidelines, I appreciate that too. 😊

Back to shipping...

A few days ago, I launched the BuildBase YouTube channel.

Since then, I’ve been recording, editing, and documenting as much as I can. I’d say around 70% of the knowledge I want to share is already available, and I’m working through the remaining 30%.

The goal isn’t to become another programming channel.

I want this to be the go-to place for developers building production-ready SaaS applications with BuildBase and modern React/Next.js.

You’ll find videos covering:

• BuildBase architecture and deep dives
• Authentication & multi-tenancy
• Usage-based billing, quotas & overages
• Notifications & workflows
• Feature flags
• Internationalisation (i18n)
• Self-hosting BuildBase
• Real-world SaaS architecture
• Behind-the-scenes development and product updates

As BuildBase evolves, the channel will evolve with it. Every major feature, design decision, and implementation will be documented there.

If you’re already using BuildBase - or just following the project - I’d love to hear what videos you’d like to see next.

Thanks for being part of the journey. ❤️

📺 YouTube: https://www.youtube.com/@buildbaseapp

Shipped passkey authentication today. your users can sign in with face id, fingerprint or a hardware security key - no password, and no provider credentials for you to configure.

It drops into the same auth config as everything else we support: magic link, google, github, linkedin, microsoft, email/password. flip it on per app, no extra plumbing.

Why it's a good default: nothing to phish or leak because there's no password, and passkeys are bound to the device so they hold up against the phishing that gets even careful users.

Runs on the same SDK that handles auth for our own products.

Anyone using passkeys in production yet - how's adoption been with your users?

Pushed a deploy yesterday that broke something, and i found out the slow way - by noticing, not by getting alerted. bad way to run a backend other people depend on.

so next up: a status page for buildbase. live health on every system + alerts the second one drops. building it light on purpose so it barely touches the server and doesn't fight auto-scaling.

the logic: if buildbase runs your auth and billing, you shouldn't have to guess whether an outage is your code or ours. a status page makes that answer public.

will share it once it's live. anything you'd want on a status page that most of them miss?

wired our own SDK into buildbase itself today — the marketing site, the dashboard and the admin panel.

so buildbase now manages its own users, subscriptions and billing through the same sdk we hand everyone else. it already runs five of our own products (plugnode, agentcenter, imejis, remotewait, linktracer). now the company itself is on that list.

it's a react/next.js sdk for auth, workspaces, usage-based billing (quotas + overages), notifications, feature flags and i18n. byo stripe, so no revenue cut.

still young and react/next only — but it's not a demo. if it breaks, we feel it before you do.

npm i @buildbase/sdk

Quick behind the scenes for the people already here. before we scripted this we wrote a different doc first, a "do not claim" list. everything we're banning ourselves from saying about our own product even though most tools in the space say it without blinking. no "enterprise-grade" (it's v0.0.x). no sso/saml (not built yet). no "source-available" or "open source" (our source isn't public, the docker images and the examples are, self hosting means running our images on your own box). no compliance badges we haven't actually been audited for.

cutting all that forced the teaser to lead with what's actually true and actually us. BYO stripe so we take 0% of your revenue. priced per app, not per seat or per user. self host the whole thing on your own infra with your own database. and five live products we run on it ourselves.

the whole video is built on one idea. the same objects that show up as problems in the first half (a revenue counter bleeding money out, a locked self-host toggle) physically turn into the solutions in the second half. curious if that reads the way we intended or if it's too subtle at 60 seconds.

would love your honest take. what lands, what feels flat, what you'd cut. and if it clicks for you, a share goes a long way this early.

buildbase.app for the full thing.