Show HN: A source-available billing system I've spent 18 months building

Original Article ↗ Hacker News Discussion ↗

License and “Source-Available” Model

  • Uses the Fair Source License (FSL), described as an evolution of BSL/BUSL with:
    • Fixed, short expiration (2 years per version), then converts to Apache 2.0 or MIT.
    • Less variability than BUSL, making it easier for legal departments to pre-approve.
  • Clarification that the 2-year clock is per version; older commits can be used under the open license once they age out.
  • Debate over terminology:
    • Some argue “source available” is too generic and often covers essentially proprietary models.
    • Others propose “Fair Source” as a clearer label for this kind of license.
  • Mixed views on value:
    • Critics say “source-available” without permissive terms is a “no man’s land.”
    • Supporters highlight reduced vendor lock-in, ability to self-host, audit, patch, and continuity akin to source escrow.

GDPR, Hosting, and Jurisdiction

  • Concern about the company being UK-based and implications for GDPR and future EU e‑billing rules.
  • Author clarifies: servers hosted with Hetzner in Germany (EU-based), intent to comply with EU laws, and willingness to relocate if needed.
  • Discussion of risks when using US cloud providers in the EU (CLOUD Act, FISA orders).
  • Noted that Germany often applies GDPR more strictly than many other EU countries.

Stripe vs. This Billing System

  • Built on top of Stripe; confusion from some about why not just use Stripe directly.
  • Claimed advantages over Stripe Billing/Tax/Invoice/Payment Links:
    • Full control over PDF and email templates and email delivery.
    • Easier handling of multiple subscription items.
    • Fine-grained tax configuration (customer, product, country, state).
    • Multiple brands under one account.
    • Lower cost than Stripe’s add-on products at certain volumes.

Tax Handling (Especially US Sales Tax)

  • System supports:
    • State-level tax rules and economic nexus thresholds in the US.
    • Product types (e.g., physical vs digital) and per-country rules.
  • Currently does not model detailed city/“polygon” jurisdictions (e.g., Chicago-specific SaaS taxes); workaround is customer-level tax overrides.
  • Plans to integrate with tools like TaxJar to keep tax rules updated.
  • Multiple commenters stress that US sales tax is extremely complex; many larger systems integrate with specialist vendors (Avalara, TaxJar).

Internationalization and Translations

  • Site is localized into multiple languages (German, Spanish, Italian, Dutch, French), but quality is widely criticized:
    • Mixed formal/informal tone, literal/misleading translations, inconsistent terminology, typos (e.g., “Deustch”).
  • Suggestions:
    • Professional linguistic review.
    • Localize screenshots.
    • Use proper i18n workflows (JSON-based libraries, TMS/CAT tools, Figma integration).
  • Project maintainer points to translation files in the repo and welcomes PRs.

Tech Stack and Deployment

  • Stack: PHP, PostgreSQL, Stripe API.
  • Some view this as “boring” (in a positive, mature sense); others call it “daring” given PHP share.
  • Docker Compose setup is provided for self-hosting.

Product Experience and Website Issues

  • Reports from trial signups of a blank dashboard showing only an “Environments” heading.
  • Comments that live UI looks worse than marketing screenshots.
  • Noted issues with responsiveness and layout whitespace.
  • Minor copy critiques (e.g., phrasing around “out of the box SDKs”).

Pricing and Target Users

  • Some consider the SaaS offering “way too expensive.”
  • Others argue it becomes cheaper than Stripe Billing/Tax/Payment Links at moderate scale, with example numbers given.
  • Target audience appears to be businesses with enough volume and customization needs to justify replacing Stripe’s higher-level products.

Value of Source Availability in Practice

  • Several commenters say they do choose products based on source access, especially when:
    • They must run it themselves.
    • They need to patch quickly without waiting on vendor support.
    • They worry about long-term continuity or vendor failure.
  • Comparison to traditional source escrow:
    • Many enterprises already require escrow; having code generally available under FSL + automatic Apache transition is seen as simpler and more equitable.