Billing is the product, not a plugin

Founders leave billing until the end because it feels like paperwork. It is the data model. Stripe’s subscriptions guide is explicit that a subscription is a customer, a price, and a collection of items, and that you listen to webhooks rather than trusting the browser redirect. The success page is not proof they paid. invoice.paid is.

Entitlements are the part teams skip. Stripe’s entitlements API maps features to products. Your application still has to read that map and refuse the screen. A boolean column named isPro, set by a success URL, is how people get a year of the product for the price of a failed card. The customer portal is the other half: Stripe hosts the page where a customer updates a card or cancels, so you are not building a second billing UI and then forgetting the cancel path. If cancel is an email to you, you do not have a product. You have a favour.

Tax, trials and proration are where the first invoice goes wrong. Stripe Tax is optional and not a substitute for advice. A trial that does not collect a payment method will not convert, and a trial that charges on day one is not a trial. Pick one and write it on the pricing page in the same words the webhook uses. Proration on a mid-cycle upgrade should be a test you run in test mode, with the card numbers Stripe publishes, before a person is attached.

Multi-tenant comes before the second customer, not after. If two organisations will ever sign in, every row they can read needs a tenant. Adding that column to a populated table is a migration on live data. One design partner is not a reason to skip it. It is the moment the assumption is cheapest to write down.

The MVP we will build is sign-up, the one job, a charge, a cancel, and an admin view of who is entitled to what. Roadmap features go in a document. They do not go in the first schema.