Common questions: payments, sign-in, models and size
Before you commit an idea here, four things are worth knowing: what payments and sign-in actually give you, why we do not default to the priciest model, and what size of app this is built for.
Which payment providers can I use?
Integrations → Payments wires in a module we compile in advance, with three providers: Stripe, Polar and Waffo. The module owns the parts that break easily — the hosted checkout, verifying the webhook signature, and refusing an event it has already processed, so nobody gets charged twice or granted twice. You and the AI only write the business rule: who paid, and what they can now use.
What it is not: an accounting system. Orders, subscriptions, refunds, invoices and payouts live in the provider’s own dashboard, and the tax/receipt machinery is not here either.
Only those three providers work. If the AI installs a different payment SDK, the build strips the dependency and deployment fails with UNSUPPORTED_PAYMENT_PROVIDER. The honest workaround: use an external checkout page from your provider and let the app link out to it — the platform treats that as just another URL.
Polar and Waffo let individuals take money without a registered company; Stripe suits a company. Waffo additionally supports WeChat Pay.
Can I add sign-in after the app is built?
Auth runs on Better Auth: email and password, sessions, password reset, and third-party providers (GitHub, Google and others) through the same integration panel. All of it can be added after the app is built — a working app does not have to be rebuilt to get accounts.
Two rules. Third-party sign-in needs an account system first, because an outside identity has to map to a user inside your app. And keys you paste — mail credentials, payment private keys — go into that app’s own secret store: never into the source, never into the git repository.
If you want email verification or two-factor, ask for it by name and set up a mail key first, then sign up and sign in once in the preview to confirm the whole path works.
Do you use the most expensive model?
Vendors change weekly, and the two top models can differ several times over in price. We default to the model that is good enough and affordable, because on a small app the quality gap is barely visible while the cost gap is not. Settings has a higher tier for the moments that genuinely need it: a heavy refactor or a very long context.
What size of app fits here?
Small apps are the home ground: a tool for yourself, an event page, a product site, a members-only shop, a panel a few people share. Each app keeps its own database and its own account system, and going live is one click.
Large systems — a CRM, an ERP, a back office for several departments — do not have the shape this platform is built for. Role matrices, approval flows and cross-module reports mean the structure gets re-litigated every few days. If that is your need, split it: one small app per job, sharing data only where you truly have to.