Marketplace listing as a feature, not a checkbox

The first time we helped a customer through an AWS Marketplace listing, it took about six weeks, and at the end everyone involved was quietly relieved to never think about it again. That relief is the trap. A listing you built once and stopped thinking about is a checkbox for the partner tier requirements. The partners actually making money through Marketplace touch it constantly, because the thing that transacts isn't the public listing, it's the private offer: a negotiated price and terms, packaged for one specific buyer, drawing down that buyer's committed AWS spend.

And private offers recur. Every deal that wants to transact through Marketplace needs one drafted, priced, approved, published to the buyer, and chased to acceptance, with an expiration date doing quiet damage in the background if the deal slips. At one customer we watched this run as an email thread between a rep, an alliance manager, and a spreadsheet of previous offers used as templates. Offer number twelve had a pricing error inherited from offer number nine. Nobody caught it until the buyer did.

What we built

In our product, the private offer is a step in the deal, not a side quest. When a deal is marked as transacting through Marketplace, the offer draft is generated from the deal itself: buyer's AWS account, negotiated terms, dimensions and duration mapped onto the listing's structure, expiration aligned with the deal's close date instead of a guess. Validation runs against the listing's actual configuration, the same pre-send philosophy as our ACE submission: if the offer can't be accepted as drafted, the human hears it now, not from the buyer.

Then the draft stops and waits, because the two decisions that matter in a private offer are exactly the two we refused to automate: the price, and the send. Pricing approval routes to whoever owns commercial terms, with the deal context and the history of that account's previous offers attached. Publication to the buyer happens on a named human's click. After acceptance, the subscription status lands back on the deal, where renewals and expirations become visible instead of becoming surprises.

Real numbers

1. ~6 weeks for our first customer listing, once. The listing is genuinely a one-time project; everything after it recurs.
2. Days → same day: private-offer drafting at one customer, from email-thread-and-spreadsheet to generated draft awaiting pricing approval.
3. 1 pricing error shipped to a buyer from template inheritance before; validation against the live listing config caught every such mismatch since.
4. 2 steps deliberately manual in the flow: the price, and the send.

Where the humans sit

Price and publication. A private offer is a contract offer; drafting it is mechanical, but deciding what a specific customer pays and choosing the moment it lands in their procurement queue are commercial judgment, and they stay with the people paid to have it. The system's contribution is that when the human makes those calls, the draft in front of them is complete, validated, and consistent with every offer that account has seen before.

Steal this

Separate the listing project from the offer workflow in your head and your planning. Budget the listing once, properly, and don't gold-plate it. Then look at your private-offer process the way you'd look at any recurring process: if it lives in an email thread with a spreadsheet of templates, it will eventually ship a wrong price, and the fix is generation-plus-validation with explicit human gates on price and send, whether you build that or buy it. And set offer expirations from the deal's close date, never from a default.

Next on this track: the strategy question underneath this post - what being listed actually buys you, what transacting buys you, and why the two get confused.

---

This post is part of the partner track of How a Tiny Team Ships Like a Big One, a series on how six builders run a production AI company. Building at Aithon - if this is how you want to work, talk to us.