Your own SaaS
A product people sign up to, on your domain and under your name, at a price you set and collect yourself.
A product that runs itself while you sell it
The app you scaffold is the thing you sell, and it is already whole. Everything a customer does after finding it — signing up, adding agents, bringing their colleagues in — happens without a message reaching you.
Customers who arrive without you
Anyone who reaches your deployment makes an account, and the app claims them a workspace and their first agent on the spot. There is nothing to approve, provision or reply to.
Their agent, made on the plan you already pay for
Your server creates it inside the Chatfuel workspace you picked in the wizard, with credentials that never reach a browser. One plan, one balance, every customer on it.
They grow their account themselves
An account adds, renames and deletes its own agents and switches between them in the top bar. A customer getting bigger costs you no work at all.
Their team, run without asking you
Customers invite their colleagues, hand out access agent by agent, change roles and pass ownership on. None of it arrives as a support request.
Tenants that cannot reach each other
Every request is checked against the agents that session may open before it leaves your server, so one customer knowing another’s agent id gets nowhere. You are shipping that isolation rather than writing it.
The screens you would rather not have built
Sign-up, sign-in, invite, password reset and a team page come with the module and wear your name. The dull half of a first version is already done.
Your name on the sign-in screen
The name and mark you give the wizard are the browser tab, the top bar and every signed-out screen your customers meet. Nothing on the way in says whose scaffold it was.
The accounts are yours, in your own database
Email and password on a Supabase project you own, with your data and your keys. The wizard can create and migrate it from an access token, or you paste the URL and keys and run the SQL yourself — and every table it adds is prefixed, so the project can hold your own alongside them.
You set the price, and they pay you
Your customers pay you directly, on your terms, at whatever you decide to charge — nothing in the app takes a cut, sets a floor or knows what you asked for. What you owe Chatfuel is the other side of it and stays the same shape: your own workspace balance, one balance behind every customer agent.
Any feature you want, in your own repository
It is a React app you own outright, so a screen nobody else sells is a directory you add and a line in the menu table. The design system, the API client and the proxy are copied in as source under MIT rather than installed, so there is no release schedule between you and the thing you thought of.
From one command to a paying customer
Accounts is the module that does it, and it is opt-in — the wizard never installs it unasked, because it needs a database it cannot invent. Pick it in the module list, or name it on the command line as auth.
- 01
Run the wizard
It asks what the app is called and what mark it wears, which modules go in it, and — the decision that matters here — which Chatfuel workspace it runs on. That workspace is the billing container: every customer’s agent is created inside it, so its plan is what pays for all of them.
- 02
It sets up the database behind sign-up
On the recommended path a Supabase access token creates or picks the project, waits for it to come up, runs the migrations and turns email and password on with no confirmation round-trip. On the manual path you paste the URL and keys, and the SQL files are written into the app for you to run yourself.
- 03
Deploy it
The deploy script ships inside the app rather than in the wizard, so the same command still works a month later. It puts the project on Vercel, and the wizard then adds the live origin to your database’s redirect allowlist, without which signing in on the real domain would fail.
- 04
Sell it
What is left is distribution and a price. Everyone you bring in signs up on their own and pays you directly, at whatever you decided to charge, and none of it passes through anything of ours. What you owe Chatfuel stays what it was before they arrived: the balance on the workspace their agents live in.
The team system you ship rather than build
Roles, invite links and access granted agent by agent are already in the product you are selling. Your customers hand these out to their own colleagues inside their own workspace, and none of it reaches you — an owner is the owner of their account, not of anything on your deployment.
| Name | Who they are | Agents they reach | Who they can invite | How the role moves |
|---|---|---|---|---|
| Owner | The account that signed up. At most one per workspace, and it is a unique index in the database that makes it one rather than a rule somebody remembered to write. | Every agent in the workspace, by role | Admins and members | Only by transfer — the owner cannot be removed, demoted or leave until somebody else has it |
| Admin | Runs the workspace day to day: members, invite links, and the agents themselves — creating, renaming, deleting and handing out access. | Every agent in the workspace, by role | Admins and members | Set by the owner or another admin, and taken back the same way |
| Member | Works in the agents they were handed. Access is a row per person per agent, added when they accept an invite carrying it or afterwards from the team page. | Only the agents granted to them | Nobody | Set by the invite that brought them in, or changed by an admin later |
FAQs
However you like — the app carries no checkout, no plans and no subscriptions, and it never reads anybody’s. Stripe, pricing and subscription types are stripped out of the API schema before the copy that ships, on the grounds that a scaffolded app has no business reading a plan. So billing is yours to bring: your prices, your provider, your terms. What you owe Chatfuel is separate and simpler — your own workspace’s balance, one balance covering every customer agent inside it.