Launch HN: Skope (YC S25) – Outcome-based pricing for software products
Here’s a demo video: https://www.youtube.com/watch?v=ORxhACQbu64
Prior to working on Skope, we built AI agents that fundraised for nonprofits. We weren’t able to find our stride within the nonprofit world, one reason being that there was no incentive for a nonprofit (with an already small budget) to take on the risk of buying expensive software claiming to replace humans at a high upfront cost, without proving its value first.
Instead, they should’ve been able to pay every time our product really worked (in this case by securing a donation or booking a meeting). With this model, we wouldn’t profit off of nonprofits with a mediocre product. At the same time, we’d give ourselves more upside if what we were selling truly did its job. All while taking all the risk off of our buyers.
Although we really wanted to, there was no easy way to make this happen at scale. It would have had to rely on trust, and depend on every single customer reporting each outcome quickly and accurately. Not the best recipe.
So, we decided to build it…which turned out to mean rebuilding billing from scratch. But we think a world where people pay for software doing its job is a good one, in which case outcome-based pricing will catch on, but don’t think it’ll happen overnight. There are a ton of wrinkles to figure out still. In the meantime, we’ve also built the rails to support traditional subscriptions and usage/credit based models with a focus on making iteration on price really easy.
How it works: Our users can easily track customer usage through units (like tokens consumed or emails sent) and set pricing rules such as the price of each unit or a limit for usage per month. These pricing rules are designed to be flexible items that can be modified easily for each customer. Usage is recorded as events uploaded via our API/SDK, which are mapped to pricing rules for accurate, immutable billing calculations. Invoices are automatically generated at the end of each billing period based on the events logged during the given period. We are working to develop integrations with LLM observability platforms such as Helicone and Langfuse to make it easy to record customer usage data. Finally, we make it easy to collect payments via Stripe (disconnected from Stripe Billing).
For outcomes specifically, we’re working on acting as a middle layer between our customers and their users. The same process for setting prices and units follows as said before, but we’ll have access to both our users’ and their customers’ systems of record to verify that these outcomes actually happened. We built a customer portal so that once outcomes are verified by us, the customer can see and validate them as they happen. If a customer of a company using Skope, wants to dispute a charge, we plan to handle it ourselves through the platform. Transparency and trust are really important between all parties within this model, so we want to do everything possible to encourage that.
We really like the outcome-based model because it encourages truly good software and aligns incentives between buyers and sellers. We think that the bar for software will become higher as more companies adopt it and it’ll lead to cool things. At the same time, neither buyers nor sellers can pull a fast one on the other to get a better deal. It’s similar to Google Ads, which introduced pay per click pricing to online advertising for the first time. We’re trying to make it possible for the entire software industry to come into the pay per performance realm, just like Google did over 20 years ago.
We’re rolling out at a flat subscription price. Counterintuitively, we don’t think the outcome-based model makes sense for Skope itself. A billing product isn’t one that “may or may not work”, it needs to just work.
The way AI companies do business needs new billing infrastructure, and that's what we’re working to provide. We have a ton to learn and are eager to hear how others see the future playing out.
Please let us know if you have any thoughts on things you’d like to see. Always excited to riff on this and we’d absolutely love your comments!
I can see why people buying/using software would want this, but why would any software startup want to use it? What are the markets (other than non-profit), where pay vs success (and not attention/friction) is the limiting factor? The idea is you’re unlocking new markets or models, right?
And when/how is success measured? Otherwise it’s just like API billing, right?
https://www.useskope.com/resources/why-now
"Salesforce, Sierra, Zendesk, and Intercom are a few of the early movers in adopting an outcome based model. Their definitions of a 'successful outcome' vary from simply facilitating a conversation (Salesforce) to completing a customer support query with no human elevation needed (Sierra)."
"Chargeflow is another company that automates the process of collecting revenue and preventing chargebacks for ecommerce, which has adopted this model. They take 25% of each recovery and charge $39 for each chargeback prevention. Their pricing page explains the idea perfectly: success first, pay second."
Are these examples of "outcome-based billing" or just the redefinition of usage and/or fees as an "outcome"? "Facilitating a conversation" and "completing a support query" are not trust-based outcomes, that's just usage. A thing happened within the service's boundary. Stripe's usage based billing (and Orb etc.) can be used for this already.
I guess you are in a tough position because you are trying to provide real world examples of a category you are hoping to define, but in this case, perhaps it's best to wait for some clear real world examples instead of muddying the waters like this. I fear that reading this, most people would conclude that outcome-based billing is just a way to define your usage-based pricing, rather than something that needs a platform like Skope.
I don't see detail here. As someone who would be interested in using this, can you clearly explain how you will measure and track the outcomes? That's the key detail that matters.
Relying on customers to self-report is not sufficient, and an automated self-report-system is not a true improvement.
Would love to chat as well (ben@useskope.com) if you have any questions specific to your use case. May be able to give a better answer, as the nuance really varies by use case.