[HN Gopher] Show HN: BillaBear - Self-Hosted SaaS Subscription M...
___________________________________________________________________
Show HN: BillaBear - Self-Hosted SaaS Subscription Management and
Billing
Author : that_guy_iain
Score : 95 points
Date : 2023-06-27 12:46 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| stevefromIT wrote:
| Great job.
|
| Add Paypal.
|
| Stripe is toxic.
| GordonS wrote:
| Is this something like an alternative to Chargebee?
| Bilal_io wrote:
| Relevant bit for those curious:
|
| > Is BillaBear Open Source?
|
| > No. BillaBear is released under the source-available license
| Business Source License. You can find it in the license.md. This
| is the same license as used by Sentry, CoackroachDB, and many
| more.
|
| > After 3-years from the release date of a version, it will then
| become open-source.
| rapnie wrote:
| It will become GPL according to the license:
| https://github.com/billabear/billabear/blob/main/LICENSE
| f_devd wrote:
| They should have put that in the README, I'm quite
| sympathetic towards the delayed-FOSS model, but the source-
| available had me write it off.
| KRAKRISMOTT wrote:
| BSL is still much better than AGPL, which is used by the
| really slimy companies like Lago (YC funded too, many new
| YC open core companies are doing this now).
|
| https://www.getlago.com/
|
| If your main customer base is other SaaS providers, then
| making the app impossible to host on the same network or
| customize is essentially a bait-and-switch poison pill.
| pgt wrote:
| Why do you consider Lago slimy?
| martypitt wrote:
| I really struggle with this attitude that companies that
| make their code available, but don't do it "open enough",
| are therefore "BadCompanies".
|
| Companies are not obligated to make their source code
| available (excl: copy-left, where they are).
|
| Those that do, often choose to do so in a way that
| balances aiding a community, and growing their business.
|
| That's a good thing IMO. Being commercially savvy, and
| ensuring the company that authors software today, will be
| here tomorrow, is good for the software, and therefore,
| for it's community.
|
| I don't understand where the sense of entitlement comes
| from that it's OK to shame/berate/insult a company who
| publishes their source code, because of the restrictions
| they elected to impose.
|
| Companies like Lago are small startups, who need to pay
| the staff to author the software. They also created a
| company to generate profits. Electing to do so under an
| Open Core model is a good thing - as we get Open Source
| software as a side-effect.
|
| They have no obligation to do so under a permissive
| license. That they do so under any license should be
| celebrated, IMO.
|
| > many new YC open core companies are doing this now.
|
| Great! Long may this continue. Companies that are open-
| core are beneficial for everyone. Splitting hairs over
| the license they elect seems ungrateful IMO.
| CitizenKane wrote:
| I'm not sure how AGPL would prevent you from hosting on
| the same network. It's pretty standard among OSS software
| companies to prevent Google, Amazon, et al. from swooping
| in and creating a competitor using their open source
| code.
| that_guy_iain wrote:
| I tried to. Clearly I didn't make it clear enough, I'll
| make it clearer that it goes to GPL after 3-years.
| f_devd wrote:
| Ah I see now it's at the end of the QA on OSS, the main
| confusion is with the initial "No. ... Source-available"
| Although it is more honest it also made me stop reading,
| switching around the paragraphs and adding the license it
| changes to (GPL3) would have fixed the confusion for me.
| ilrwbwrkhv wrote:
| Another one of these open source projects which are such an
| eyesore that I want to pluck out my eyes. Please for the love of
| God, make them look nice or just have it run in the terminal.
| martypitt wrote:
| Looks like pull requests are open.
|
| Excited to see what you contribute.
| dimmke wrote:
| I was just talking to a friend last night about how I didn't know
| of any good off the shelf solutions for this sort of thing in the
| Node ecosystem like Laravel Spark. But it looks like this is also
| built in PHP. Is it headless- where the person implements their
| own UI and simply hits the REST api? It could probably work if
| it's just a container.
|
| I'm in a position where I need to build something like this, but
| there's still a lot of things I haven't dealt with. The thing I'm
| building could potentially have thousands of different custom
| subscription plans - can this accommodate that?
|
| Also, how tightly coupled to Stripe is it? My other concern is
| that Stripe shuts down accounts so whatever solution I settle on,
| I'm looking for a "dumb pipe" approach where the vast majority of
| things are handled by the software and the payment processor can
| be replaced quickly.
|
| Also I tried to go to your user documentation and got a 403
| forbidden error.
| racl101 wrote:
| I thought it was an invoicing system like Invoice Ninja at first.
| gregoriol wrote:
| How is it supposed to work if "Webhooks to listen for billing
| events" is on the roadmap? This is a strict requirement for any
| billing system...
| that_guy_iain wrote:
| Well, it listens to Stripe webhooks, but it doesn't have it's
| own webhooks system. I guess I should make that clearer to.
| gregoriol wrote:
| I mean: how do you integrate a billing system like BillBear
| into your own development, when there are no hooks available
| for situations like a payment success/failure or a new
| invoice being generated? This makes it almost useless
| that_guy_iain wrote:
| For many systems at the start they don't need it. But
| obivously for more complex systems they will which is why
| it's super high on the todo list.
|
| For more complex and mature applications there are tons of
| functionality still needed. Tax reports, subscription
| reports, auditing, webhooks, etc. But I wanted to get
| something released so I could start getting feedback on
| what to work on first instead of just guessing what needs
| done and never releasing.
|
| As is, for indie hackers it'll get the majority of the job
| done and more. And for quite a few SaaS platforms. It's
| when it comes to mature applications is where it's just not
| there yet.
| naiv wrote:
| Feedback as an experienced Symfony developer:
|
| I am not sure if this is the first time you work with
| Symfony but before going to add anything new you should
| really improve the code quality, add static analysers
| like Phpstan and Psalm, bring them to level 9 and 1,
| restructure your src dir, create reasonable entities,
| improve the unit tests.
|
| Also, your license needs to be reviewed by legal and your
| it insurance company (I hope you have one as you will
| need one for sure working in the billing area), it is
| completely flawed. I think you just copied it from
| somewhere and added your information.
| Kiro wrote:
| What do you mean? I don't know any billing system where
| webhooks is an essential. You normally post billing events to
| an API.
| [deleted]
| dbbk wrote:
| Are you serious? Any payment that relies on 3D Secure?
| Chargebacks?
| itake wrote:
| I've been running my mobile app for 2+ years and never bothered
| supporting webhooks. It hasn't been an issue yet.
|
| Nefarious users can deconstruct my app to by-pass payments, but
| the juice to support them isn't worth the squeeze. If someone
| is willing to go through that much effort, they must really
| want to use my app and I will let them enjoy their prize :)
| montroser wrote:
| > BillaBear is a standalone Subscription Management and Billing
| System that integrates with Stripe
|
| This confused me -- is it standalone, or is it a front-end for
| Stripe?
|
| FYI, the links for "User Documentation" and "Technical
| Documentation" in your readme.md are pointing to the wrong place.
| that_guy_iain wrote:
| > This confused me -- is it standalone, or is it a front-end
| for Stripe?
|
| It's both. Which is a bit confusing to be fair. My main idea
| was to target folk who are using Stripe Billing but want to
| migrate away or have more control over things. So you can
| continue to use Stripe Billing and use BillaBear for email
| templates, invoices, subscription management and have invoice
| customers which are separate.
|
| Or you're able to have a complete standalone billing process
| which just uses Stripe for payments. You're also able to
| migrate away from Stripe Billing to a standalone billing system
| by importing data from Stripe and then disabling the Stripe
| billing - which will go through and cancel the subscriptions
| and then bill them manually.
|
| > FYI, the links for "User Documentation" and "Technical
| Documentation" in your readme.md are pointing to the wrong
| place.
|
| Thanks! The doc site deployment process process. I've fixed
| that and the links will start to work.
| eevo wrote:
| Here's our main problem with Stripe for what it's worth -
|
| Stripe Subscriptions and Subscription Schedules are massively
| complicated and don't support our use case. Subscriptions
| support complex scenarios like proration and metered billing,
| but miss the mark on simple use cases.
|
| All I want to do is ship products when people are charged,
| but I also want to move the next charge (or next several
| charges around) based on end user requests. This is
| accomplished in Stripe using their "trial" functionality -
| which is a hack because the Subscription isn't in "trial",
| the customer just wanted to move the next invoice. Putting
| the Subscription in "trial" screws up Stripe out of the box
| analytics because they don't get counted as active
| Subscriptions.
|
| I'm not surprised you were driven to build your own
| Subscription platform, I wasn't around for the decision for
| us, but knowing what I know now, I probably would have built
| as well or looked at Chargebee or similar.
| bjord wrote:
| Is effectively what you're wanting to do "snooze" a
| subscription? Given that you can schedule subscriptions to
| start at a later date, maybe a better (albeit still hacky)
| way to handle that scenario might involve canceling the
| active subscription and scheduling a new one to start at a
| later date? That way you can ship on any subscription
| renewal, but still track "snoozed" subscriptions within
| stripe itself?
|
| Interestingly, we actually have the opposite problem--our
| subscription model (effectively a payment plan) is so
| specialized that no-one, stripe included, supports our
| requirements out of the box.
|
| EDIT: I re-read your comment and saw that you mentioned
| wanting to track active subscriptions easily, so I'm not
| sure my suggestion really solves your problem. Maybe you
| could classify any scheduled subscriptions as
| active/paused, if you're not using them anywhere else in
| your billing system?
| eevo wrote:
| Yeah you're right, it's another hacky way to solve it.
| Also yes, invoice at either a later date, earlier date,
| or immediately.
|
| Another hacky way my CX team has been solving moving the
| next invoice date around is to pause their subscriptions
| then unpause/bill now (Stripe supports bill now but not
| reschedule next out of the box) - they'll set calendar
| invites for themselves to unpause when the customer
| requested then blow through them in the morning in the
| Stripe UI. At least we've upgraded from that scenario to
| the current "trial hack" scenario. We can pull analytics
| and treat "trial" as active, it's just annoying that
| their dashboard analytics are hard baked to treat trial
| as inactive.
|
| I really think what Stripe did was launch Subscription
| then get a bunch of customer requests, created
| Subscription Schedules which was supposed to be the layer
| of advanced functionality you opt in to if you really
| need it, but created a product that's too complicated and
| misses the mark.
|
| Oh another fun note I'll leave you with - we never want
| proration (the price of the product is always the price,
| since we're shipping physical products). But the
| proration radio is always on. So a team member using the
| Stripe UI forgets to turn it off every few days or so and
| we charge the customer the wrong amount (and have to
| sidestep proration line items when shipping)
| pc86 wrote:
| A couple questions about this:
|
| 1. Does "lifetime upgrade license" mean you can upgrade forever
| without any additional fees?
|
| 2. Is the standard upgrade license going to behave that way as
| well, or will it be valid for a certain period of time and/or
| number of upgrades?
|
| 3. Emailing for pricing on a very tech-oriented, non-Enterprise,
| _automated billing_ SaaS product seems like a chance to try to
| just gauge how much I can pay rather than just having set
| pricing. Or like you just haven 't decided how much to charge
| yet.
|
| 4. Who did the logo at the top of the readme? I love it.
| qup wrote:
| > 4. Who did the logo at the top of the readme? I love it.
|
| Seriously? I think we should consider it controversial, then,
| as I have the opposite reaction.
| fourseventy wrote:
| Stripe already has great subscription management. We use it for
| our SaaS billing. It seems like BillaBear is just a bad UI on top
| of what Stripe already offers?
| stevefromIT wrote:
| Rude
| esafak wrote:
| To put it another way: how is billabear better or different?
| gunapologist99 wrote:
| Perhaps you could change "It seems like.." to something like,
| "What does Billabear offer beyond what Stripe already offers?"
|
| You might like to re-read the site guidelines,. especially the
| "In Comments" section:
| https://news.ycombinator.com/newsguidelines.html
| joewils wrote:
| What's the reasoning behind the lack of transparent pricing?
|
| > "How much does BillaBear cost? To get pricing email
| sales@billabear.com."
| esafak wrote:
| Price optimization?
| DeMoXz wrote:
| Did you have any Saas platform in order to use your application ?
| hbcondo714 wrote:
| Great to see another tool for helping folks manage their SaaS.
| BillaBear does remind me of Kill Bill - Open-Source Subscription
| Billing and Payments Platform discussed here last year:
|
| https://news.ycombinator.com/item?id=33263603
___________________________________________________________________
(page generated 2023-06-27 23:01 UTC)