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

Original Article ↗ Hacker News Discussion ↗

A new source-available billing platform, BillaBear, is drawing interest for using the Fair Source License (FSL), which keeps the code source-available under commercial terms for two years before converting to Apache 2.0. Commenters weigh its appeal versus Stripe Billing—highlighting potential cost savings, customizability (PDFs, emails, tax rules, multi-brand support), and reduced vendor lock‑in—while noting it currently sits on top of Stripe and mainly uses a PHP/Postgres stack. There is also scrutiny of its readiness for complex regulatory and localization needs, including GDPR data residency, EU e‑invoicing rules, and especially nuanced US sales tax handling, as well as criticism of the quality of non‑English translations.

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.