Run an indie hacker's CRM, support, and changelog on Slab5

You don't need Stripe + HubSpot + Intercom + a CMS + a changelog tool to ship. You need one workspace and about thirty minutes.

Here's the setup for an indie product running on Slab5.

The thirty-minute setup

1. Create a Slab5 account. Create one workspace for the product. 2. Create one API key for your marketing site and forms (scopes: crm:write, cms:read, support:write). The workspace owner role is fine for this key since it's yours. 3. Create one MCP client for your AI assistant. Assign it the agent workspace role. Start read-only: crm:read, support:read, cms:read, tasks:read. 4. Create three CMS collections: pages, blog_posts, changelog. 5. Create one Support queue: Inbound. 6. Done.

The rest is filling in content.

Form to lead

Your landing page form posts to POST /v1/leads. Every signup, every "interested in beta" email, every newsletter subscriber lands in your CRM. You get a real audit trail and a real list, not 14 different signup forms living in different SaaS dashboards.

For a solo founder, that single endpoint replaces ConvertKit + a HubSpot trial + a Google Form. Add a webhook into your Slack DMs so you actually see signups as they happen.

Inbox to ticket

Forward support@yourproduct.com into a small worker (an email-to-webhook service, or your own 50-line Node script) that calls POST /v1/support/tickets. Inbound becomes structured. You stop losing customer emails because they fell off the second page of Gmail.

Replies go out from your normal email client — you don't need a hosted helpdesk UI on day one. You just need a list.

Changelog as a CMS collection

The changelog collection has fields: title, summary, release_date, category (Feature, Fix, Performance, Breaking). Every release: one entry.

Your landing page renders the last ten entries. Your in-app changelog widget hits GET /v1/cms/entries?collection=changelog&limit=10. Customers see what changed. You see a publicly-shippable record of what you've built.

This is the single most underrated thing an indie product can have. It turns the question "is this thing still being worked on?" into a paragraph of evidence.

One MCP agent for everything

The assistant you ask things like:

• "How many leads came in last week?"
• "What support tickets are still open?"
• "Summarize the questions I got this month for my newsletter."
• "Draft a changelog entry for the bug fix I shipped today."

Start it read-only as above. Once you have a couple of weeks of audit log behavior you like, promote it to tasks:write and cms:write so it can create follow-up tasks and draft changelog entries you publish yourself.

It is not autonomous. It is a very fast intern that you check the work of.

What you skip on day one

• Multiple workspaces.
• A custom domain model in CMS collections. Stick with the basics first.
• BI dashboards. You don't have enough data for them to matter.
• Webhooks beyond a Slack notifier.

The whole stack costs you the price of a Production Starter plan and a couple hours of setup. The first time a customer writes in and you already have their lead, deal, and prior support history in one screen, you stop missing the four-tool world.

One MCP client with the agent workspace role. Phase 1 (week 1): read-only scopes everywhere. Phase 2 (after audit-log review): add tasks:write and cms:write for follow-up tasks and changelog drafts. Convention: never transition CMS entries to published; that's a human action.

Form → POST /v1/leads. Email-to-ticket worker → POST /v1/support/tickets. Site → GET /v1/cms/entries?collection=.... One workspace, one API key, one MCP client.