Billing for side projects

What side project billing actually needs

A small paid tool needs more than a checkout link. It needs products, prices, a way to know who paid, webhook fulfillment, access checks, customer recovery, and a tiny admin surface when something goes wrong.

• Checkout creation for one-time purchases, credit packs, and subscriptions.
• Webhook verification so payment state turns into app access.
• Wallets or external user mapping so access survives refreshes and devices.
• UI for balances, purchase prompts, feature gates, and billing portal links.
• A dashboard for orders, wallets, providers, products, and support adjustments.

The division of responsibility

Keep the payment provider responsible for payment processing, invoices, taxes, cards, refunds, and subscription billing. Put neonFin between your app and that provider so your product code only has to ask simple questions: can this user buy, spend, or access this feature?

• Stripe or Polar owns money, invoices, tax behavior, and payment methods.
• neonFin owns projects, products, prices, wallets, credits, gates, and fulfillment.
• Your app owns the product experience and calls a small client API.

A minimal integration path

Start with the smallest useful path: one project, one provider, one product, one price, and one gated action. Add subscriptions, one-time feature unlocks, or external auth only when the project actually needs them.

• Create a neonFin project for the app you want to monetize.
• Connect Stripe or Polar once from the provider screen.
• Create a product and price that match what the user buys.
• Install the shadcn registry components into your app.
• Show a balance, open checkout when needed, and deduct credits when work starts.

const { deduct } = useCredits();

<CreditGate cost={10}>
  <Button onClick={() => deduct(10)}>
    Process file
  </Button>
</CreditGate>

When this is the right fit

neonFin is intentionally strongest for small developer products: AI wrappers, generators, file processors, internal utilities, indie SaaS experiments, templates, and tools that are useful enough to charge for but too small to deserve a bespoke billing system.

• You want to charge in an afternoon, not turn billing into a sprint.
• You ship multiple small tools and want one shared billing service.
• You want payment components that live in your codebase and match your theme.
• You do not want to force auth just to sell credits or access.