AI Strategy · Field Note

Product of One: Two Sleeps to a Live AWS Marketplace Product

The services-versus-product fork is a false choice when each engagement can precipitate live inventory. Here is the new rung — and the verification bar that has to travel with it.

By Scott Farrell · LeverageAI · Field note, mid-2026

I was not looking for a product company.

I was sitting with a set of my own wikis — career, dev projects, frameworks — asking the kind of question that usually produces useless answers: how do I make money from this stack? Asked of a generic model, that question returns segment averages. Asked against a map of what I have actually built, who I have been talking to, and which muscles are already warm, it ranks options like a partner who has seen the books.

On that map, the textbook move lost. Pure productisation looked cleaner on a whiteboard. The service path had more legs, clearer value, and an easier sale. Then the thing I did not ask for arrived: not a slogan about productising services, but a concrete inventory form. What if the engagement leaves behind an AWS Marketplace app?

That is the shape I am naming: Product of One. Services that precipitate a deployed product per engagement. The product becomes the proposal.

The dilemma that dissolved

Boutique operators live inside a permanent fork. Services: high trust, high margin, hard to scale, always for sale again next quarter. Product: the dream of leverage, the multi-year roadmap, the segment you hope is real. Boards and mentors push product. Cash and relationships pull services. You pick a side and feel half wrong either way.

Product of One does not compromise between those poles. It changes the unit of output. Each engagement still sells as a service — diagnosis, judgment, relationship, accountability. But the delivery motion is allowed to leave inventory: something deployed, listable, and specific to that client’s operating reality. You keep service economics. You also accumulate assets that were not slideware.

That option is almost invisible to generic strategy advice, because generic advice optimises for segment averages. A vertical-of-one only appears when the system can see your capability map and this client’s context at the same time. Economies of specificity — customise per customer when customisation is cheap — stop being a pricing slogan and become a shipping pattern.

If you have already been compiling bespoke proposals from a kernel of frameworks plus deep client research, you already live next door to this idea. Product of One is what happens when the compile target upgrades from a document to running infrastructure.

The product is the proposal

I have written the ancestor move as the Proposal Compiler / Marketplace of One: AI collapses the cost of customisation, so a 30-page company-specific proposal can be cheaper and more credible than a template, and the artefact itself is the proof — the way you sold them is the way you will serve them.

Product of One inverts the medium again.

The two-pass structure does not need reinventing. Pass one: your kernel — frameworks, constraints, voice, known failure shapes. Pass two: this client’s context. What changes is the artefact class. Meta-credibility escalates with the medium. “Here is how we think” becomes “here is the thing already running under marketplace governance; try a transaction.”

That escalation is a gift and a trap. A document that overclaims is embarrassing. A product story that overclaims is fraud-adjacent theatre. If the sales motion is “believe the listing,” the listing’s provenance is not a side concern. It is the product.

Field note: two sleeps (claimed, not yet receipted)

Spec window. After the Marketplace idea landed, I opened a fresh thread, handed over AWS account keys to an environment that was already low-risk, and spent on the order of two hours writing the outline I actually wanted. Detailed specs. Constraints. What “done” meant. Wiki access so the harness was not inventing my methodology from model priors. You have to know what you want before you rent overnight labour from a machine that will happily build the wrong cathedral with great confidence.

Overnight lane. Then an agentic harness — batch cadence, reviewable artefacts, room to fail and repair, platform rules as the outer cage — worked the problem while I was not in the loop. I am not going to re-teach overnight orchestration here; the lane is familiar if you have already shipped in multi-hour agent sessions. What matters for Product of One is the target: not a repo only, but a marketplace-shaped product path.

What the agent said I woke up to. Coded. Deployed. Smoke-tested. An AWS Marketplace product path with app and dev-license shape. Synthetic transactions pushed through “to test that it does what it says on the tin.” Not clean on first pass — fixes, another run at approval, more testing. Then teardown of the test rig, according to the same report. Wall clock from idea-shaped to that wake-up: roughly twenty-four to thirty-six hours. In human units: two sleeps.

The evidence package is part of the product

I have already argued the general rule under a different name: do not accept oracles from nested AI components; require witnesses. An evidence package is claim plus exhibit plus resolvable pointer plus a confession of what could not be verified. That convention exists so hallucination cannot compound silently through agent chains.

Product of One applies the same rule to the whole overnight shift, including the shift that supposedly just created your sales artefact.

Before this field note graduates from claim to case:

1. AWS console state — what is actually provisioned, where, under which account and region.
2. The bill — including the signal that test infrastructure was torn down rather than left quietly accruing.
3. Live listing URL — a pointer a third party can open, not a path that only exists in a chat log.
4. One transaction record under human hands — synthetic or real, but operated by you, not only narrated by the agent.

Ten minutes of receipts can convert a great story into a demonstrable one. Without them, you are selling vibes with a marketplace costume. That is not a pedantic footnote for the end of a blog post. It is the load-bearing definition of the offer.

If the product is the proposal, the product must clear the credibility bar the proposal used to clear with research receipts and rejected alternatives. Meta-credibility is not a brand colour. It is a chain of custody. An agent saying “approved” is hearsay until the listing resolves. An agent saying “torn down” is hearsay until the bill agrees.

And if the receipts fail? That is not a PR disaster for Product of One. That is the method working. You learned the overnight path is not yet trustworthy for client-facing inventory, and you file the walk transcript as a failure shape instead of a victory lap. Witness discipline protects the framework from becoming another AI hero story that collapses on first demo.

The self-referential flywheel

The loop that produced this field note is almost too neat, which is why it is useful to say out loud.

A wiki of frameworks and past work informed a strategy conversation that generic models answer badly. That conversation selected a non-average move: productise services via per-engagement inventory. The same wiki-backed kernel fed the build specs. The overnight harness claimed to emit a product. The product, the specs, and — if captured — the walk transcript of the night itself become new soft data that can re-enter the wiki.

That is not a party trick. It is the commercial shape: context compounds, inventory compounds, and verification compounds. Each engagement should leave the kernel smarter about what product forms work, which approval paths are fragile, which specs were underspecified, and which client contexts justify a Product of One versus a document-only Proposal Compiler pass.

The organisations that only capture the shipped binary — the listing, the repo tag — and delete the deliberation will keep relearning the same night from scratch. Conversation is the source code; artefacts are the compile. If you only keep the binary, you cannot recompile.

What to do with this if you sell services

You do not need an AWS Marketplace listing to use the idea. You need three decisions:

1. Name the inventory form for your next engagement — marketplace app, private SaaS instance, deployed agent endpoint, client-scoped data product. Something that runs, not something that only narrates.
2. Keep the two-pass compile — stable kernel of how you work; variable context of this client. Do not let the overnight harness invent your methodology.
3. Budget the evidence package as non-optional delivery — console, bill, URL, one human transaction — before anyone tells the two-sleep story outside the room that ran it.

If those three are present, the services-versus-product argument softens. You are not abandoning services for a product company. You are allowing each paid relationship to precipitate inventory that sells the next conversation by existing.

If those three are missing, you have either a normal services business (fine) or an unverified agent anecdote (not fine). Product of One is the name for the first path with receipts. It is not a brand for the second.

I will update this field note when the evidence package is in hand — or when it fails. Either outcome is publishable under witness rules. Only one of them is a client demo.

Until then, the honest sentence is the useful one: two sleeps to a claimed AWS Marketplace product, pending receipts. The framework still stands. The instance is on probation. That is what Product of One demands of itself.

Scott Farrell advises Australian mid-market boards and C-suites on AI capital allocation, governance, and architecture. He writes at leverageai.com.au. No hosted ebook exists for this piece yet; the framework is a candidate for promotion once a second engagement instance and a verified evidence package exist.