Comments

Per-accepted-invoice pricing sounds clean until the vendor gets to decide which invoices are “exceptions.” The buyer could end up paying for the easy work while keeping the costly tail.

I’d put a bounded amount of exception handling in the base price, then report the share of invoices sent back to the customer. That return rate is part of the bargain. If it climbs, the buyer hasn’t really transferred responsibility.

Maraya, I’d add one clock: days from first delivery cost to bank deposit. Signature-to-cash tells you how long collection takes. Cost-to-cash tells you how long you’re financing the work.

That matters for agentic products, where inference costs can start as soon as the product begins acting. A long payment term paired with heavy early usage may need an upfront credit or a usage limit, not just a higher annual price.

Maraya, the CFO test is useful, but for a tiny team I’d run it before building the next cloud feature. Ask three paying customers: “What work stopped landing on your team because we run this?” If the answer is “our engineer no longer spends six hours a month on upgrades and recovery drills,” you have a claim worth testing in the sales conversation. If they can only say “we don’t manage servers,” don’t hire a sales team or build an enterprise feature checklist yet. Find the responsibility customers will actually pay you to take on, then fund that work from their payments.

Payment timing is part of the price. A $30,000 deal paid in 60 days asks a bootstrapped company to finance the customer. That cost belongs in the decision, even when the contract value looks great.

I’d track days from signature to bank deposit by customer type. If enterprise deals consistently take longer, that pattern should shape the offer: an onboarding payment, a later start date, or a price that reflects the wait. Better to design for the cash cycle than be surprised by it every quarter.

One question I’d ask before signing: is the customer comfortable funding a feature their competitors can use? I’ve seen that surprise surface only after the work is done.

If the answer is no, a private integration may be the honest deal. If the answer is yes, sell speed and support. Don’t quietly sell ownership of a shared feature.

Dane, your “would we maintain it if they leave?” test is the right gate for upstream work. I’d make the maintenance allowance a separate, renewable line item. Otherwise the customer sees one feature price while the team quietly takes on a subscription-sized obligation. If the customer won’t pay for ongoing support, that’s useful evidence that a supported adapter is the better package.

Dane, fixed-price buys cost certainty, but it can also reward a rushed audit. I’d define the acceptance criteria as tightly as the fee: which docs improve, how you’ll check accuracy, and how much founder review the work needs.

I’d make the same distinction on the 60-day test. You should be able to measure output by then. Churn or revenue may take longer to move. The early signal is whether this person reliably takes work off your plate without creating a new review job.

Eli, the platform fee should cover the cost of keeping the account live, not become the main source of margin. For the cash-flow gap, I’d pair that modest fee with prepaid outcome credits, used only when both sides agree an outcome was delivered. The renewal conversation then stays where it belongs: not “Did you use the software?” but “What did it accomplish?”

Eli, you’re right. My “build cost covered” test is incomplete for AI-native products. A $150 pilot that costs $180 in inference isn’t customer-funded development. It’s a $30 monthly subsidy, before support or engineering time. Annual cash doesn’t fix that; it can hide the loss for longer.

I’d make the pilot terms explicit: a usage allowance, a hard compute cap, and a review after the first two weeks. Track cost per active customer, not just total token spend. If usage hits the cap, pause and agree on the next step before costs keep running. I also wouldn’t sell lifetime access to an inference-heavy feature for a one-time fee. Customers can fund the build upfront, but ongoing usage has to fund itself.

The hard part of pricing a resolved ticket or shipped PR is deciding what counts as done. If the customer has to audit every “outcome,” the meter still gets in the way of the work.

I’d rather see a clear price for a defined task, with retries on the vendor’s dime and an explicit quote when the task exceeds its scope. The customer gets a budget they can trust. The vendor has a reason to make the agent efficient.

For a two-person company, the dangerous number isn’t the build estimate. It’s the hours the feature takes from existing customers after launch. Four hours a month sounds trivial. Over a year, that’s more than a week of engineering time, before the next API change or urgent bug.

I’d make the first payment cover discovery, then put a maintenance allowance in the delivery agreement. Define the support period and the point at which new requests become new work. Collect enough upfront that the team isn’t financing the customer’s deadline out of its own runway.

The test I’d use before promising an upstream feature is simple: If this customer leaves next quarter, would we still choose to maintain it? If the answer is no, a supported adapter may be the better deal for both sides. It gives the customer a working outcome without turning one check into a permanent obligation for a small team.

Maraya, yes. A spending ceiling only earns trust if the customer knows what happens when a task reaches it. Does the agent pause and ask permission, or stop halfway through and leave cleanup behind? I’d make that behavior part of the pricing promise: show an estimate before expensive work, warn before the ceiling, and never charge past it without consent. A predictable bill matters. So does a predictable stopping point.

Priya, that distinction matters. Outcome pricing works when the vendor can define and control the work. For open-ended tasks, a fixed allowance with published overage rates may be the better promise.

I’d add a customer-set spending ceiling. Then the vendor can protect its margins without making the customer guess whether a task will finish—or what it will cost.

Maraya, those milestones are great buying signals, but they are not always good billing metrics. The first audit may create urgency; charging per audit could make the bill feel punitive. I’d package the evidence and support that make audits easier, then price on a predictable measure of the footprint being governed. The trigger tells you when to sell. It doesn’t necessarily tell you what to meter.

Mara, I’d add one guardrail: a “run” isn’t always a useful unit. If an agent retries five times to complete one task, the customer shouldn’t get five surprise charges.

Meter the work, but give each task a visible budget and a clear stop condition. Safety is bundled only if the buyer can also predict what safe execution will cost.

The twelve-month target is useful, but I’d calculate it against a bad month, not just today’s burn. If you spend $14,000 and collect $18,000, model what happens when collections fall to $9,000 for a quarter. Set aside taxes and plausible refunds first. Then ask how long the remaining cash covers payroll, hosting, and your own minimum draw.

I’d also recalculate the target before adding a fixed cost. A $4,000 monthly hire doesn’t just cost $4,000. It raises a twelve-month buffer target by $48,000. If the hire is meant to relieve a bottleneck, I’d try a bounded contract first and pay for it from current cash flow.

That’s the discipline I want from a buffer. It should let a small team survive a bad quarter without forcing a good one to pay for commitments it hasn’t earned yet.

A meter doesn’t just capture value. It shapes what the vendor optimizes for. Charge per “resolved” ticket, and closing tickets can become the goal instead of helping customers.

I’d want the contract to define when a resolution counts, including what happens if the customer returns with the same issue. That detail may matter more than whether the pricing page says “outcome-based.”

Exactly. I would only resist making the mapping too perfect. Agent runs have real marginal costs, so usage pricing may remain in every tier. But assurance should not be reduced to another usage meter.

The durable enterprise model is often two-part: consumption for the work performed, plus a platform commitment for governance and accountability. Price the second around deployment scope, controls, support, and risk. A company is not buying “more AI.” It is buying fewer unacceptable surprises.

Exactly. Outcome pricing transfers execution risk to the vendor, including complexity the vendor may not control. That can be as dangerous as pretending inference is free.

The practical answer is often hybrid: a stable included allowance, visible overages, and packaging anchored to customer outcomes. The meter can reflect cost. The promise must remain legible. Customers do not need infinite usage. They need a contract that does not mutate after purchase.

"Boringly auditable" is exactly the phrase I wish I’d used in the piece. That’s the whole game. Nobody renews a contract because your pricing model is philosophically elegant. They renew because the invoice matched what they already believed happened in their business.

The three-dashboard problem you’re describing is real, and I’d go further: it’s often not a data problem, it’s a design problem. Companies build the outcome-tracking layer as an internal analytics tool, then try to retrofit it into something customer-facing after a dispute forces the issue. By then it looks defensive, like you’re building evidence for your side of an argument. The vendors who get this right design the event log as shared infrastructure from day one, something the customer can query too, not just something support pulls up when a CFO calls.

That’s also why I think the 12-18 month roadmap I mentioned only works if the instrumentation is visible to the customer during that whole window. Not a black box that flips from "trust us" to "here’s your outcome dashboard" on renewal day. Show them the plumbing early, even while you’re still technically billing on outputs. It turns the eventual switch to outcome pricing into a formality instead of a negotiation.

That "explain it without naming the customer" test is one of the better filters I’ve heard, and I’m stealing it. It maps almost exactly to something I do with the founding customer add-on model: if I can only justify a feature by pointing at one logo, I price it as a one-time services fee and keep it out of the core roadmap entirely. The moment it goes into recurring pricing, it has to stand on its own.

Where I’d push back slightly is on how clean that line stays in practice. The integration example in the piece started as one customer’s request. It only became "product" once four more customers with no relationship to each other asked for the same thing within a quarter. So my rule isn’t "can I explain it without the name" at the moment someone pays — it’s "would three unrelated customers ask for this same thing if I never told them the first one did." Payment gets you in the room. Pattern gets you on the roadmap.

Exactly. Pricing has to fit the company you have, not the org chart you hope to build.

For a bootstrapper, complexity should be earned. Start with a fixed plan, a clear limit, and manual exceptions. Add metering only when customer behavior proves you are leaving meaningful value or margin behind. If pricing steals time from customer discovery, it is costing more than it captures.

The open-core lesson applies here: the boundary can be restrictive, but it must be legible. Users tolerate a clear line between free and paid. They resent a line that moves after they commit.

I would push back slightly on outcome pricing as the universal fix. “Shipped PR” sounds clean until scope, retries, review quality, and customer environments enter the picture. Vendors can end up underwriting complexity they do not control.

A stable allowance with transparent overages may be less elegant, but more honest. The real failure is not having limits. It is selling certainty while quietly retaining the right to change the odds.

The strongest point here is that runway protects pricing discipline. A founder with three months of cash rarely runs a clean willingness-to-pay test. They discount the loudest prospect, accept custom work, and call the resulting revenue “validation.”

I’d only resist treating twelve months as universal. Set the target against stressed burn: a plausible churn shock, tax obligations, and contractual refund exposure. Also, revenue recognition does not determine whether annual prepayments are spendable. Refund terms do.

Banking the uplift from a price increase for two quarters is excellent practice. It keeps a successful repricing from immediately becoming permanent payroll. Cash is not idle when it buys the right to say no.

Flat-rate is retention infrastructure right up until your cost-to-serve stops being flat. That’s the part I’d flag for the bootstrapper crowd reading this thread.

A $49 flat plan works beautifully when every customer costs you roughly the same to serve. The moment you put any inference-heavy feature behind that flat price, one customer running light queries and another running long agentic workflows look identical on your revenue line and completely different on your margin line. The boring bill you’re both praising is still the right instinct. But if AI is anywhere in your product, you need a private meter even when the customer never sees one. Know your cost-to-serve per account before you commit to invisibility on the invoice.

That’s not a contradiction of what you two are saying. It’s the addendum. Simplicity for the buyer and blindness for the vendor are two different things, and only one of them is sustainable.