You have a Resolution Spec, a mechanism choice, and an oracle story. This chapter is the deployment fork: list on someone else’s rails, or own matching, custody, compliance, and wallet UX end to end. Major on-chain platforms showed how hybrids scaled—and what you inherit or must rebuild when things break. Regulation is not a chapter you read last; it is often the constraint surface that picks the fork before architecture debates finish.
Most teams should launch first and build only where margin and licensing justify operations hell.
Platform comparison chapters contrasted Kalshi, Polymarket, and play-money cousins from a trader risk-budget lens. This chapter is the founder mirror: rent distribution and compliance, or pay years to own the stack.
Time and team reality
A five-person product team can launch curated markets on a host in weeks. The same team cannot ship audited matching, wallet, oracle adapters, and compliance in a quarter. Be honest about calendar math in investor decks—build timelines measured in years are normal for regulated USD, not a sign of failure.
Launch on a platform: what you buy and give up
Launch means days to weeks to first market, compliance mostly hosted, mechanism and oracle adapters you do not maintain, and distribution you rent for twenty to forty percent economics. You give up listing control, some fee share, policy risk if the host delists your category, and the tail risk of platform pause. You still own spec quality, distribution, community trust, and honest cross-promo—disputes hit your brand even when the host resolves.
Paths include US regulated DCM partnerships (CLOB, operations oracle, USD rails), crypto-hosted stacks (AMM or hybrid, wallet UX, optimistic disputes), DAO protocol UIs (permissionless create, INVALID literacy), white-label SaaS (speed, thin differentiation), and internal enterprise tools (HR/legal wrapper, no retail liquidity).
Recruiting US persons to offshore crypto via VPN exports legal risk to users and reputational risk to you if marketing winks at bypass. Say what you mean about access.
Build from scratch: when it is rational
Build means quarters to years, compliance entirely yours, full choice of matching and oracle, brand upside, and your bug plus your enforcement first. Justified when core IP is matching or oracle invention, you need custom bundles day one, you cannot survive host category delists, or regulation and banking require your entity anyway.
Stack options range from forking conditional-token patterns with custom UI, to custom AMM only, to full CLOB plus surveillance, to the rare full vertical (legal entity, banking, chain)—capital and license timelines measured in years, not sprints. On-chain everything taxes retail UX; industry norm at scale is hybrid off-chain matching with on-chain settlement.
Ten honest questions
Need US retail USD in ninety days with fewer than five engineers? Lean launch. Differentiation is niche events and content, not matching invention? Lean launch. OK paying host economics and accepting their dispute rules? Lean launch. Core bet is proprietary matching, custom bundles, or surviving without a host’s policy? Lean build. Liquidity budget under a hundred thousand dollars? Launch and curate marquees—building an empty CLOB is an expensive hobby.
Three archetypes
A media brand election hub should curate tight specs and drive traffic, not build surveillance and maker ops. Partner regulated APIs for clean USD storytelling or crypto hosts for global crypto audiences—skip custom chains that distract from media IP.
A DeFi protocol “truth layer” needs moat: conditional-token fork, optimistic parameters, audit culture, INVALID education—not white-label only.
A corporate supply-chain risk desk wants internal LMSR-style liquidity and multisig resolution under employment and data policies—not public offshore venues that leak sensitive information.
What you still own on “launch”
Template library quality determines delists. Distribution determines whether liquidity follows eyeballs. Cross-venue comparisons must warn when resolution text differs—same headline, different contract, as foundations stressed.
Host APIs still require your discipline: creation flows are not permission to ship vague verbs. Webhooks on assert and finalize should drive customer support macros, not surprise your community team.
What you must own on “build”
Contract audits, oracle parameters, surveillance, customer agreements, incident response with pause and comms, collateral and banking choices. Smart contract exploit risk is yours alone. False asserts follow bonds you set. Regulatory enforcement knocks your door first.
Forking battle-tested primitives beats reimplementing Augur-era complexity on day one. Most successful crypto launches reused collateral patterns and invested in templates and ops, not novel curve math.
Risk transfer in plain terms
On a platform, contract exploits are shared blame; oracle policy is shared; delisting is platform policy; stablecoin stress is shared. When you build, each of those becomes your first-line problem. Traders may not care about your cap table—they care whether withdrawals work after a headline dispute.
Sequenced strategy most startups should copy
Launch five to ten clean markets on a host. Measure volume, dispute rate, and customer acquisition cost. If economics hurt and volume justifies it, spec mechanism migration and compliance spend. Fork contracts and hire counsel when data says so—not when ego says so. Case studies like Polymarket scaled by phases, not by copying day-one stack complexity.
Common mistakes
Build for ego and burn runway without depth. Launch without spec discipline and eat delists plus brand damage. Market US users into offshore hosts and invite enforcement. Underestimate maker programs and show empty books. Copy headline hybrid maturity before you have TVL, templates, or ops runbooks.
Economics of the fork
Launch rent is often twenty to forty percent of economics—fees, rev share, or listing constraints—but you avoid years of license burn. Build captures margin if volume justifies compliance headcount and audit spend. Model break-even notional before you fork contracts: host tax hurts less than empty books hurt more.
Integration checklist on launch
Read host creation API limits: outcome count, end time, fee tiers are expensive to change. Wire webhooks for assert, challenge, finalize. Train support on host dispute pages. Keep your spec hash in your CMS so marketing embeds match settlement text.
When build becomes mandatory
Regulation may require your entity for US retail USD. Core IP may be a matching innovation you cannot rent. Host policy may ban your category tomorrow. Those are build signals—not “we prefer Solidity.”
Support and brand when the host resolves
Users will DM you when the host disputes, even if legally the host settles. Train support on spec links and freeze timelines. Your brand is on the line in every post-mortem thread.
Key ideas
Launch optimizes time, compliance, and liquidity rent; build optimizes control at capital cost. Spec quality travels either way. Sequence launch → measure → build unless law or IP forbids waiting. Bad specs are bad everywhere.
What comes next
Where the market lives is chosen. Next is the problem that kills most roadmaps after launch week: why the spread is eight cents and the mid jumps on fifty dollars.
Write a one-page decision memo: launch path, build path, break-even notional, and what you still own either way. If you cannot fill it in an hour, you are not ready to incorporate.
Next: Bootstrapping Liquidity