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 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. 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 fi...