Commercialization
From Stablecoin Infrastructure to Commercial Adoption
Working settlement infrastructure is not a commercial proposition. A practical framework for choosing the first buyer, pricing the switch, and sequencing proof.
- By
- Michael Stanat, founder
- Published
- Read
- 8 minutes
Key points
- A capability describes what the system does. A proposition names a buyer, their alternative, and the cost you remove.
- Payments buyers are risk buyers, so the plan has to budget for proof: integration, review, and a parallel run.
- Separate load-bearing partners from announcements. If a partner going quiet for six months does not move the launch date, they are not in the critical path.
Choose the buyer who produces the cheapest, fastest, most repeatable proof, not the buyer who represents the largest addressable market. In practice that means someone who can already state what their current arrangement costs, whose path to first live volume is short, whose integration pattern resembles the next twenty, and whose market is reachable under the regulatory position you hold today. The rest of this piece is how to get to that answer.
There is a specific moment in a stablecoin company’s life that looks like success and behaves like a stall. The rails work. Testnet is behind you. A handful of counterparties have moved real value through the system and nothing broke. Then the commercial questions arrive, and the answers turn out to be softer than the technology.
Who buys this. What are they replacing. Why would they change something that currently works, given that the thing it moves is money.
The gap is not a marketing problem. It is a sequencing problem, and in this framework it takes a similar shape across issuers, orchestration layers, payout networks, and settlement providers.
Capability is not a proposition
A capability is what the system can do. A proposition is a specific claim to a specific buyer that a named alternative is worse.
“We can settle in USDC across twelve corridors” is a capability. “For payout providers running weekend disbursements into Latin America, we remove the Friday cutoff and the pre-funded float that comes with it” is closer to a proposition, because it names who, what they do today, and what it costs them.
The distinction matters because capability language is comfortable. It is defensible, technically accurate, and never wrong. It is also unusable by a salesperson, a partner, or an investor trying to model your market. Teams stay in capability language for a long time because moving to a proposition requires choosing, and choosing means someone in the room loses an argument about their preferred use case.
The switching cost problem
Payments buyers are not evaluating a better product. They are evaluating a change to something that currently moves their money without incident. That framing changes the commercial math in three ways.
The status quo has a low visible cost. The float, the cutoff windows, the reconciliation labor, and the failed-payment recovery are usually absorbed into operating cost rather than tracked as a line item. Part of commercialization is making the current cost visible enough to compare against. If the buyer cannot state what the existing arrangement costs them, they have no basis for switching and no internal argument to make on your behalf.
Proof is expensive to produce. Nobody trials settlement infrastructure casually. There is an integration, a risk review, a counterparty assessment, and usually a period of parallel running where the buyer pays for both systems. The commercial plan has to include who absorbs that cost and how the path to first live volume is made cheap. Companies that skip this design a motion that stalls in procurement and then blame the sales team.
The decision is distributed. Treasury cares about counterparty risk and liquidity. Operations cares about reconciliation and exception handling. Engineering cares about integration burden and failure modes. Compliance cares about the perimeter. A narrative that only satisfies one of these gets stopped by another, quietly, several weeks after the enthusiasm peaked.
Choosing the first buyer
The temptation is to pick the largest addressable segment. The better criterion is which segment produces the cheapest, fastest, most repeatable proof.
Four questions, applied honestly, narrow most lists within a week.
Where is the pain already priced? Look for buyers who can already state what the current arrangement costs them, in float, in fees, in headcount, or in failed transactions. Segments that need to be educated about their own cost structure move more slowly than the plan usually assumes.
How short is the path to first live volume? Count the integration weeks, the approvals, and the parallel-run period. A segment with a four-week path and moderate value beats a segment with a six-month path and large value, because the first one generates the references that make the second one possible.
Does the win generalize? A customer whose requirements are idiosyncratic produces revenue and no repeatability. A customer whose integration pattern, risk review, and use case resemble twenty others produces a template.
What is the regulatory dependency? Some segments and geographies are reachable this year. Some are not, regardless of demand. Treating this as a legal footnote rather than a sequencing constraint is a common way for a launch date to move by a quarter or two.
Sequence proof, not features
Once a first buyer is chosen, the roadmap question changes from what to build to what to prove, in what order.
A useful sequence looks like a series of claims, each with a cheaper test than the one after it. Can we move value for one counterparty on a defined corridor without manual intervention. Can we do it at a volume that stresses the operational model. Can a second customer integrate without bespoke engineering. Can the unit economics survive at the price the buyer will accept.
Each of those is a decision point with a date attached, and each has a defined failure signal. Roadmaps built as feature lists carry no failure signal, so they can continue long after the underlying thesis has weakened.
Partners: load-bearing versus decorative
Most commercialization plans include a partner map, and the map often conflates two very different things.
A load-bearing partner is one whose absence stops the plan. A custodian, a licensed local payout partner, a platform that owns the distribution relationship. These have to be sequenced, contracted, and given a reason to prioritize you over the other integrations in their queue.
A decorative partner produces an announcement. There is nothing wrong with announcements, but a plan that depends on them is a plan without distribution. The clarifying question is simple: if this partner does nothing for six months, does the launch still happen. If yes, the partner is not in the critical path and should not be resourced as though they are.
What this means for operators
If you are inside this problem right now, three moves are usually available immediately.
Write the proposition in one sentence that names the buyer, the alternative, and the specific cost you remove. If three people on the leadership team write it separately and produce three different sentences, that gap is your actual commercial problem, and it is worth a week to resolve.
Cost out the path to first live volume for your two most likely segments. Integration weeks, approvals, parallel running, and who pays for each. The cheaper path usually deserves the next quarter even when the other segment is larger.
Separate the partner list into load-bearing and decorative, and staff accordingly. It is easy to be over-invested in announcements and under-invested in the two or three relationships that actually gate the launch.
None of this requires new technology. It requires deciding, and then writing the decision down where the team can act on it.
Related work
The method behind this piece is stablecoin and payments commercialization, and the related project format is the Stablecoin Commercialization Sprint. If the first buyer sits in another market, the same sequencing problem appears differently in payments GTM for emerging markets.
This article presents an operating framework developed by Michael Stanat. It is not legal, regulatory, or investment advice.
More resources
- Designing Payments GTM for Emerging MarketsWhy the home-market playbook stops working across borders, and how to structure expansion around local payments, distribution, and proof economics.
- Where Agentic Workflows Create Leverage in FintechMany fintech AI pilots produce a demo and no operating change. A selection framework based on verification cost, error consequence, and control surface design.