Build the part that is yours.
Before anyone can try your idea it needs sign-up, teams, data that one customer cannot read from another, a way to charge, and email that arrives. That is weeks of work that has nothing to do with what you are building. Four of those are open-source packages you install and run on your own database. The fifth is free in production too.
Five packages, and the weeks they give back.
Every product needs these, and they work the same way in all of them. They are on the public npm registry, they run inside your application on a database you already operate, and nothing calls back to QuxKit while your product is running.
Accounts, sessions, password reset, second factors and API keys, in your own database. Sign-out ends the session everywhere, which is the part most hand-rolled auth gets wrong.
Teams, invitations and per-tenant isolation enforced by the database with row-level security, so a query that forgets whose rows it is reading returns nothing instead of someone else’s.
Metering, plans, subscriptions, invoices and a double-entry ledger, against Stripe or any other provider. Amounts are integer minor units, so no float ever touches money.
Transactional email, templates and a send log, with the DKIM key held by you. Switching provider later is configuration rather than a rewrite.
The shared shapes the kits compose over: one database executor, one opaque tenant id, one Money type. It is why four libraries behave like one foundation.
Run it yourself, let us run it, or have it drafted.
The same kits sit behind all three, so the first choice is not a decision you are stuck with. Most first products start on the hosted free tier and move later, or never.
Your machine, your database, your repository. Nothing to sign up for.
- Five packages on the public npm registry
- Runs on a Postgres you already have
- No call back to QuxKit at runtime
- Read every line before you trust it
The same kits, run for you, when setting up infrastructure is not the thing you are trying to learn.
- A workspace of your own, no card
- Every kit live, judged by using it
- Upgrades and backups handled
- Leaving means running the same code elsewhere
Describe the product. A crew of agents plans it and writes it on these kits, grounded in their real documentation.
- An architect, a backend, a frontend and a reviewer
- Every file arrives as a tool call, not scraped from prose
- The whole run is kept: plan, steps, files, failures
- Take the generation as a zip. It is your repo
The Builder writes code, and it is not a no-code tool. Four agents plan and write a real application on these kits, and you take the generation away as a repository you can read, change and run anywhere. That is the whole point of it. A no-code platform hands you something that runs only inside the platform, which is the arrangement the rest of this site exists to argue against. See the Builder.
Three steps, and the third one is your product.
Install the kits into an application of your own, or start free on QuxCloud and skip operating anything. Both run the same code, so the choice is not permanent.
Add the packages for the jobs your product needs. They run against a Postgres database you point them at, and each one brings its own schema.
Sign-up, teams, isolation, billing and email are already behaving. What is left is the product, which is the only part no library could have written for you.
The published packages are @quxkit/sdk, @quxkit/identity-kit, @quxkit/tenant-kit, @quxkit/billing-kit, @quxkit/mail-kit. On QuxCloud the first step is npx @quxkit/quxcloud login.
Free to build on. A licence to resell.
Worth reading once now rather than discovering later. The line is not how much money you make. It is whether your customers are buying your product or buying the kit.
Charge whatever you like, raise money, grow as large as you can. tenant-kit, identity-kit, mail-kit and the sdk are Apache-2.0. billing-kit is source-available and free in production, including to bill your own customers. No seat check, no key, no call home, and no conversation with us required.
Offering a protected kit as a hosted service of its own, or putting one inside a product that competes with it, is not covered by the free terms and needs a commercial licence. The per-seat pieces, which include UI-Kit and the Builder’s engine, are licensed separately whatever you build with them.
If you are building a product and running it for your own customers, the free terms cover you. If you are not certain, ask us. We would rather tell you it is free than have you wonder about it for a year.
The full terms are on open core, and each licence ships inside its own package, so you can read the one that binds you before you install it rather than after.
The things worth knowing before you start.
What do I actually have to build myself for a first product?
Your product. Auth, teams, per-customer data isolation, billing and transactional email are the same every time, and on QuxKit they are libraries you install rather than things you write: identity-kit, tenant-kit, billing-kit and mail-kit, composed over the @quxkit/sdk shared shapes. What is left is the part only you can build, which is the reason you are making the thing.
Is QuxKit free for a first-time founder?
Yes, for building and selling your own product. tenant-kit, identity-kit, mail-kit and @quxkit/sdk are Apache-2.0 on npm. billing-kit is source-available under BUSL-1.1 and free in production, including to bill your own customers, with each version converting to Apache-2.0 on its change date. QuxCloud, the hosted option, starts free with no card. You pay to have QuxKit host it, or for a commercial licence if you want to resell a kit itself as a service.
Can I resell QuxKit or build a product on it that I sell?
Selling your own product that happens to run on these kits is free and needs no licence or conversation. Reselling a kit itself is different: offering a protected kit as a hosted service of its own, or embedding one in a product that competes with it, requires a commercial licence. The line is whether customers are buying your product or buying the kit.
Does QuxKit give me a no-code builder?
No, and the distinction matters if you want to own what you build. The Builder is a crew of four agents that writes a real application on these kits and hands you the repository, so you leave with source code you can read, change and run anywhere. A no-code platform gives you something that only runs inside it. QuxKit is built on the opposite position: the foundation should be yours to read, run and keep.
Do I need to know Postgres or row-level security to start?
No. tenant-kit creates and enforces the isolation policies for you, and the kits run migrations against a database you point them at. Starting on QuxCloud means not operating one at all. The reason isolation is enforced in the database rather than in application code is that a forgotten WHERE clause in one query is how customer data leaks, and a database policy cannot be forgotten.
What happens to my code and my data if I stop paying?
The libraries are yours under their licences whatever you pay, and they run on your own database, so there is no runtime dependency on QuxKit to switch off. Leaving the hosted option means running the same code somewhere else. That is a migration you control rather than a contract you have to escape.
How is this different from using Stripe, Clerk or Auth0?
Those are services you rent: the user table and the ledger live on their side, and your product reaches them over the network. These are libraries that run inside your application on your database, so the rows are yours to query, join and export. billing-kit also speaks to Stripe or Paddle as providers, so taking payments through Stripe and owning your ledger are not a choice you have to make.
How fast can I get a prototype in front of someone?
The fastest honest answer is that the plumbing stops being the long pole. Sign-up, teams, isolation, a subscription and a working email send are installs and configuration rather than weeks of work, which leaves the schedule to the part of the product that is actually yours.
Start with the part that is yours.
A workspace of your own, no card, every kit running live. Or install the packages and never sign up for anything.