Rafsark

12 ms·

91.
The tech stack we use to build Lago (YC S21), the open source billing API
5 points by Rafsark 4y ago|1 comments
92.
by Rafsark 4y ago
The PDF is triggered when it’s requested from the UI or from the API. The job is asynchrone, so it’s returned when it’s ready (generally in milliseconds). This prevents performance issues
93.
by Rafsark 4y ago
We make the whole fee calculation easy to do. If you have a paying feature, the charge related to it can be implemented in few minutes. We handle automatically the upgrades, downgrades, invoices, subscription dates and boundaries, and a lo
94.
by Rafsark 4y ago
Actually, this is only a feature Lago is providing. We have a full billing API to create usage based billing, subscription based billing and hybrid pricing. If you need to charge and invoice your clients, you don’t want to build this yourse
95.
by Rafsark 4y ago
@mellosouls love you title also!
96.
by Rafsark 4y ago
You can self host Lago for free under AGPLv3 licence. You have access to the entire billing service (UI, API and all related services). Feel free if you need a proper demo
97.
by Rafsark 4y ago
Did you face any implementation difficulties with your solution?
98.
by Rafsark 4y ago
Yep, that’s a solution. But editing millions of invoices would cost way to much I guess. Depending on your company size and what you want to achieve though
99.
by Rafsark 4y ago
Hi Dewey, The company is open source, so the pricing is… free! We’ve written this only for the fully cloud hosted solution. As we are in alpha, we haven’t figured out our pricing grid yet. You will be the first to know!
100.
Stripe Billing Is Now Open Source(getlago.com)
2 points by Rafsark 4y ago|0 comments
101.
WDYT: Should we get the hell out of Europe after pivoting?(twitter.com)
5 points by Rafsark 4y ago|0 comments
102.
Engineers need open source to end their billing nightmares(getlago.com)
6 points by Rafsark 4y ago|0 comments
103.
by Rafsark 4y ago
Yes, upgrades and downgrades were painful for me too. I think it's due to different subscription dates between all our customers, having to create specific code for each edge case. In the end, it works, but so much harder than I though
104.
by Rafsark 4y ago
You are totally right. But, somehow, most of the engineers working on those topics don't want to work on financial system. They are just part of a company and take this topic "because someone has to take it". They accumulate
105.
by Rafsark 4y ago
It's a difficult topic to tackle; The financial leader has different needs than the tech one. One needs a perfect report with exact match day over day, month over month, year over year. The second one needs to do the math to calculate
106.
by Rafsark 4y ago
In my opinion, the best way to do it is ingesting events in a relational db with an idempotency key to prevent duplicated events. Some companies don't need real time billing data, so you could just use it to aggregate these events with
107.
by Rafsark 4y ago
Stripe offers simple metering, but in the end, you make the job of calculating metering charges (aggregate all usage and send the value to stripe). It’s becoming harder when you are an API or a cloud company who want to bill a server usage
108.
by Rafsark 4y ago
Why is it a problem to use an API?
109.
by Rafsark 4y ago
Agreed! But I do prefer to build it for me rather than someone else’s startup, though
110.
by Rafsark 4y ago
Yep, do agree that non tech team created a lot of pricing complexities, sometimes without any reasons. Remember a marketing team updating plans on webflow and telling the product team « see, not that hard » ;) Ended up with a whole squad o
111.
by Rafsark 4y ago
The marketing team of my previous company created a whole fake price plan that never existed in the code base. Somehow it works to drag acquisition, but it’s a pain in the ** to explain why it’s not as easy as updating webflow ;)
112.
by Rafsark 4y ago
Do you have a dedicated team in charge of it?
113.
by Rafsark 4y ago
Wow, haven’t lived this pain fortunately… but totally understand how hard it is to try building a « modern pricing stack » but being forced to create invoices in old softwares like SAP…
114.
by Rafsark 4y ago
The article just scratches the surface too. I could have written a book to describe it! Reporting for revenue is a hard game, indeed. Spent a lot of time trying to reconcile revenue streams in the same company we ended up building the whole
115.
by Rafsark 4y ago
Yep, totally right. Same at the previous company we worked for and built the billing logic. You start doing it in house because the first version is simple. It’s getting complicated when you keep adding paying features to a product. Often s
116.
by Rafsark 4y ago
Yep you are right, indeed. We could have mentioned Reporting/Analytics for revenue, which is always a huge pain for companies!
117.
by Rafsark 4y ago
Agreed! this triggers also complex behaviors because sales people want to handle this in their env (Salesforce, hubspot or whatever); You also have to build the logic to update subscriptions and pricing directly from it, in a two-way sync.
118.
by Rafsark 4y ago
Job creation comes always because of hard-things to build; When getting easier, it cuts job!
119.
by Rafsark 4y ago
Even if with blockchain and crypto you need to define a logic to bill your customer. This logic is pre-transactional and define how much you need to price the transaction.
120.
by Rafsark 4y ago
Couldn't agree more! I do think the best way to do it is to log ingested events in a db, and decide which way you want to aggregate a billable feature at a defined billable period. This way lets you (i) keep track of everything, (ii) i

More ›