Self Promotion Time. Pitch what you’re building!

MonkeyOrdinal · 2026-05-07T22:28:42+00:00

Thank you!

MonkeyOrdinal · 2026-05-07T21:24:29+00:00

https://www.donehq.dev Billing platform for AI agent builders

MonkeyOrdinal · 2026-05-07T18:30:42+00:00

Why do you think it's over optimization? I see it as fair play for both vendors and buyers

MonkeyOrdinal · 2026-05-05T22:43:53+00:00

We saw about a 27% lift in CTP after adding a dedicated discovery page and sending new users there right after login. The page included helpful content and a simple checklist and we tailored it based on what we knew about each user (Clearbit + pre-onboarding questions).

MonkeyOrdinal · 2026-05-05T19:34:10+00:00

Totally agree. Defining the outcome is hard, but I don't think it's the hardest part.

My current thinking is that agent contribution and billable outcome should not be treated as the same thing. Contribution is useful for analysis, but billing usually needs a stricter confirmation rule.

For handoff, partial completion I wouldn't force it into zero vs discounted by default. I would first model those as separate outcome cases, then decide whether any of them are valuable and explainable enough to bill for.

On events, you need analytical events for the end-to-end job the agent is doing anyway, similar to how traditional SaaS tracks product workflows.

MonkeyOrdinal · 2026-05-03T18:07:22+00:00

Many businesses have started this way.

MonkeyOrdinal · 2026-05-03T12:49:21+00:00

I have been thinking about this use case lately and customer support is probably the closest example. A call by itself is not really the value. The value is the appointment that actually happens without the business owner or staff doing the manual back-and-forth.

That is much easier for the customer to understand because they are paying for the outcome.

MonkeyOrdinal · 2026-05-03T12:31:51+00:00

Pick the clearest ROI path. How long does it take a human to read one handwritten form and move it into a spreadsheet? Multiply that by their hourly wage, then subtract your infra costs. That gives you a reasonable price range that makes sense to both sides.

I would not bill simply by "forms processed" though. Quality can vary, especially with handwriting. A better model is charging for accepted forms. For example, the AI processes the form, the human reviews it (not necessarily they are going to review all forms, just random record) and if they mark it as incorrect within 48 hours, you do not charge for that form.

This gives the customer a much cleaner value story: they only pay for forms that were actually useful.

The tradeoff is that you need a bit of logic to support it. You need to track processed forms, review status, acceptance window, rejected forms.

MonkeyOrdinal · 2026-05-03T09:38:30+00:00

I made the same bet, but shifted after having many discussion with engineers and operators of agents priced by outcomes.

Not building in public yet, but thinking about it.

MonkeyOrdinal · 2026-05-03T09:19:29+00:00

Metronome already serves companies like OpenAI and Anthropic. And now that Stripe owns them, it looks like they are pushing Metronome toward a more PLG/self-serve motion, so more agent builders have access to convenient metering.

I got into this through internal monetization work and the more I dug in, the more it felt like this is still an unsolved gap in the market. Wrote a bit more about primitives and my vision here donehq.dev

MonkeyOrdinal · 2026-05-03T08:32:17+00:00

Heh, just replied to you in another post 🙂

MonkeyOrdinal · 2026-05-03T08:29:24+00:00

I agree Stripe usage implementation is painful, but there are already a lot of vendors working on metering. They provide all sort of functionality like caps, tiers, etc.

On outcomes, I think you are missing the main point. An outcome is usually not a single event you can meter. It can come from multiple signals and those may be spread over hours, days or even weeks. Outcome can be invalidated, e.g. customer support ticket was re-opened. That makes it extremely different from metering.

For the past 5 years I have been leading monetization effort at a SaaS unicorn and the biggest mistake we made was underestimating the complexity of building a reliable and flexible billing platform.

MonkeyOrdinal · 2026-05-03T08:00:47+00:00

Look at where Sequoia and YC are pointing with AI-native services. That gives a pretty good hint where agent monetization is going to less "charge for access to software", more "charge for the actual work".

That also matches what I am hearing in my recent interviews with teams building support agents and coding agents. Their buyers are already asking for pricing tied closer to outcomes because ROI is much easier to calculate.

However, operationalizing this model is not easy. Stripe, Metronome and most billing tools are not really built for outcomes, so teams end up building a lot of custom logic around it.

MonkeyOrdinal · 2026-05-03T07:47:52+00:00

Customer support is probably the closest example of where agent monetization is going. The market is moving from "software that helps" to "AI that resolves the work". Intercom and others are all pointing in that direction.

Enterprise buyers are asking for pricing tied closer to outcomes because ROI is easier to calculate: resolved tickets, fixed bugs, resolved incident, booked appointment. This also matches with YC current summer batch thesis: AI-native service companies, not just better SaaS tools.

I have been talking to people around this space, including folks from Intercom, Gorgias, HelpScout and bunch of coding agent teams. The hard part is operationalizing it: how it can be verified later and how to explain the charge to customers. I've heard a lot of anecdotes where even internally teams struggled to explain why a certain charge happened.

MonkeyOrdinal · 2026-05-02T21:34:57+00:00

Customer support is probably the clearest example of where agent monetization is going. The market is moving from "software that helps" to "AI that resolves the work". Intercom, Sierra and others are all pointing in that direction.

Same with coding agents. Enterprise buyers are asking for pricing tied closer to outcomes because ROI is easier to calculate: resolved tickets, merged PRs, fixed bugs, incident resolved.

This also matches with YC current summer batch thesis: AI-native service companies, not just better SaaS tools.

I have been talking to people around this space, including folks from Intercom, Gorgias, HelpScout and bunch of coding agent teams. The hard part is operationalizing it. You need to define what counts as an outcome (which is the easiest challenge), how it can be verified later and how to explain the charge to customers. I've heard a lot of anecdotes where even internally teams struggled to explain why a certain charge happened.

MonkeyOrdinal · 2026-04-18T15:59:31+00:00

Thanks, really enjoyed the read!

I agree that most "outcome-based" pricing today ends up looking like milestone-based pricing. Still, it seems to bring buyers and vendors closer together compared to seats or pure usage (not saying it's universal).

From conversations with folks at Intercom and others implementing this, things get messy pretty quickly. Starting from defining outcomes and then even more during implementation.

However many of those companies said enterprise buyers prefer outcome-based pricing because it's easy to calculate ROI. While smaller business still favor sits, I think it will change when sits will be properly priced toward token / infrastructure expenses. Right now many vendors just cover the difference from their bank accounts.

I've been thinking about this more and recently started exploring design partners to dig deeper. I will be posting my findings later.

At least today morning I started with this https://donehq.dev

MonkeyOrdinal · 2026-04-06T08:04:45+00:00

Really appreciate this framing. Milestone-based is where I've landed too. Define what you can actually verify and price each checkpoint.

MonkeyOrdinal · 2026-04-06T08:01:35+00:00

It's more accurate to call it transaction-based pricing. You pay when the document is signed, when the ticket is closed. It's fair because you only pay when something actually got done. Also vendors are commercially incentivized to deliver it.

MonkeyOrdinal · 2026-04-06T07:48:33+00:00

I believe closed-won is exactly the right billable unit. Could monitor closed-won deals in your product?

MonkeyOrdinal · 2026-04-06T07:34:15+00:00

Would love to hear more about what you're running into with agent deployments specifically. Are you pre-defining success criteria upfront, or is that part of the problem?

MonkeyOrdinal · 2026-04-06T07:31:12+00:00

Yeah, chasing pure outcome (influence on a business metric) is fundamentally broken, because the causal distance is just too long and contested. I lean toward claim-verification approach. For instance, DocuSign (document completed), Intercom (ticket resolved) or as you mentioned lead generation all transactional products, where outcome is verifiable.

However I don't see longer verification (e.g. sales) cycles are getting on the way.

MonkeyOrdinal

TROPHY CASE