I'm aligned with your comment. I feel like it saved us a lot of time, even creating a product from scratch & before PMF. We started with a simple one, without over-engineering the DS
I do think there are a lot of advantages before PMF too.
Somehow, if you need to pivot and throw away you initial product, you can start over a new one pretty easily if your design system is on point. At least, we had this strong feeling when we had to pivot.
Yes, it's currently part of our scope. I think the hardest part of credit notes is whether the invoice is paid or still to be paid.
If I'm taking the example of an invoice to be paid, you can issue a credit note that can overwrite the amount of the invoice.
However, if the invoice is paid, you can either refund or assign credits to a customer.
The hardest part here is to know what to do when adjusting a past invoice
As a company founder, that's exactly the profiles I'm hunting when starting a new business. However, based on my previous experiences, the company won't hire this kind of profiles when the business scales, and you could get bored sooner vs later. Your company can even ask you to specialized yourself. I feel like your profile is perfect for early-stage, but you will be an eternal "unsatisfied" employee when the company grows
That's probably something I would see "on-top" of Notion. I really like the formulas on steroid, but having another tool inside the company is a bit painful. Notion team could authorize add-ons built on top...
We built an open source usage based billing with Lago (YC S21). You deploy a Postgres database with all useful objects to run your billing (events, subscriptions, plans, prepaid credits, customers, invoices …).
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
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 lot of prebuilt charge model (graduated pricing, percentage pricing, package pricing…).
We adapt to any pricing use case easily!
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 yourself. The invoice is generated automatically and can be downloaded from the UI or the API.
Give it a closer look, happy to show you more!
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
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
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!
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 thought
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 the tech knowledge, but not necessarily the whole accounting part
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 instant consumption of the product. If we add marketing leaders of a company to it, it brings creativity to the extreme (like inventing new prices, just to use it "as a hack"). Same goal (revenue), but definitely not the same path to success
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 the aggregation function that fits your need for a certain feature. Thus, you have the flexibility of (i) calculating pretty much everything you want, (ii) give granularity of usage to your customers and (iii) be closer to real time (you play the query anytime you need it).
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 for instance. Calculations are getting heavy, costful and hard to maintain. This is why I do think stripe is not a usage based solution, and also the reason why I decided to create a company trying to solve this pain :)
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 of engineers called « the pricing cross functional team » …
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 ;)
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…
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 billing system. It’s also not easy because metering is not something that is predictable nor easy to make it fit into a finance report.