6 ms·
Launch HN: Paigo (YC S22) – Measure and bill SaaS customers based on usage
Hey HN! Daniel here, I’m a software engineer and hobbyist hacker. I’m joined by my cofounder Matt. We’re building Paigo (https://paigo.tech https://paigo.tech). We make it easy for SaaS businesses to bill customers based on usage.
To get your hands dirty a bit we have a stateless and signupless demo you can try out: https://hn.paigo.tech/ https://hn.paigo.tech/ and a video of me walking through the system in a bit more detail: https://youtu.be/T6J1Yh8GhdU https://youtu.be/T6J1Yh8GhdU.
The idea of our platform is fairly straightforward: You give us read-only access to your SaaS backend and based on tenant metadata for your infrastructure, we measure, persist, and aggregate SaaS tenant usage data to give a clear picture of per-client usage. We can measure metrics like API requests, Compute time, Data Storage, Transaction Volumes and many more. Some common scenarios would be: an ML platform could use Paigo to track processed input files for customers, a Data platform could use Paigo to determine the data size customers have consumed, and an API company can use Paigo to track customers’ API requests. Additionally, we also help you understand your cost to serve your clients’ usage, and this data allows us to provide your SaaS with usage based billing.
What’s the problem we are solving? Many SaaS products need to measure their customer's usage in some form, and many want to incorporate it into their billing plans. It’s fairly annoying to either build the entire system in house or to build a measurement system in house and then connect to a billing provider. It takes months to get a usage based billing system up and running and usually requires several engineers (if not more) to maintain and operate. Also, when Sales wants to offer specific discounts or deals to major enterprises, it’s typically handled outside of the in-house system in Excel spreadsheets with some good guesses. This is how a lot of money gets lost for major deals.
With Paigo we handle 100% of the measurement and collection of SaaS customers’ usage for the business. SaaS business can see their customers’ usage within 10 minutes, because all they need to do is give us read access to their cloud account. Since we pull the lower level infra-data we can additionally give information like per tenant cost, and profit margin.
Matt and I came to this project after we built similar internal billing systems at previous jobs and we realized how error-prone these systems can be—one incident might have even undercharged a client by a few million dollars! We also realized there was no solution which integrated directly to a backend system and handled the measurement and gathering of usage data as well as providing the end billing integration to platforms like stripe, AWS marketplace, or through ACH.
To get into the technical details Paigo has a few measurement systems to measure different forms of usage data: infrastructure-based, where we connect directly to cloud APIs then to slice-and-dice per tenant usage data; agent-based, where our agent is deployed into a runtime to gather usage like pod cpu time, memory, and file read write, along with any exported metrics that are prometheus compatible; and datastore-based, where we connect directly to datastores like S3, Kinesis, or log file. We require that the data in the datastore based approach adhere to a standard data format so we can process it. However this allows us to Pull, any custom metrics and dimensions directly from your Datastore. All of this data is then processed and sent to our backend usage journal, where we store it in an append-only ledger pattern.
For clients to search, and aggregate their data into an end bill or to slice and dice their client’s cost and usage we have an API clients can use. We’re an API first company, which is why our demo can work with Retool—the demo is just a very thin skin over our API. The API is a NestJS based application, currently running in AWS Lambda with API-Gateway.
We bill based on invoiced revenue (surprise surprise its usage based) and we have a platform fee, roughly it breaks down to 1% of invoiced revenue on Paigo. Note that pricing is not currently transparent on our website. Our typical customers are mid-sized enterprises where an initial sales call is typically expected. However, we will be updating our main webpage soon to have some self-service options.
For a bit of deeper dive on the measurement engine we have some docs here: https://docs.paigo.tech/ https://docs.paigo.tech/
Thanks for taking time to read! Let us know what you hate and maybe what you love :P. We’d also love to hear your thoughts and experiences with measuring customer usage and usage-based billing!
- cdolan 4y agoSounds useful. Not sure I’d trade a 1% reduction in revenue across the board for this though.
- twosdai 4y agoFor transparency, we're at an early stage and its much more useful for us to have more clients using and working with the software. Reporting bugs, telling us what they need etc... We're definitely open to negotiating on price, and we don't want it to be a blocker for people to use the platform. That being said we still want to charge something to indicate a level of seriousness to the use. For some context on how we arrived to the figure the ~1% figure is in the low end ballpark for how much we saw companies spend internally on their billing systems built in house, and its slightly higher but still in the same range as other billing providers.
- danielmarkbruce 4y agoJust my 2 cents - don't reduce the price. If someone isn't getting enough value out of it they likely aren't the right customer and might pull you all over the place with requests. If someone is running $100m through your system they are going to call to negotiate anyway, you don't have to advertise it.
- Temporary_31337 4y agoYeah, it's probably not a good fit if a customer for usage based pricing doesn't want to pay usage based pricing themselves ;)
- ignoramous 4y agoSpot on. I'm sure the YC group partners have told them as much: https://www.ycombinator.com/blog/why-does-your-company-deserve-more-money/ https://www.ycombinator.com/blog/why-does-your-company-deser... https://blog.ycombinator.com/users-you-dont-want/ https://blog.ycombinator.com/users-you-dont-want/ Though, I understand the apprehension behind having to pay 1% of the revenue. It is a psychological thing mostly (in a way, the potential costs seem bottomless like with card payments, even though 1% is actually a super-good deal for small tech shops).