Powerful smart contracts in the hands of the consumer

The app opened on a wallet, not on the thing people came to do

• First build led with balances and a connect-wallet wall
• Users had to understand crypto before they could start an agreement
• The "make a deal with someone" job was buried two screens deep

Reframed around the agreement, not the wallet

• Home leads with "start a contract", the wallet recedes
• Demo wallet auto-generated so people can try before connecting
• Crypto mechanics deferred to the moment they actually matter

Early copy spoke in protocol terms, not human ones

• Screens said "UTxO", "datum", "validator", "min-ADA"
• Loan steps were named after contract states, not user intent
• Testing showed people couldn't tell if they'd been paid

A plain-English layer over the contract

• Every state mapped to a human sentence ("Alex has repaid you")
• Amounts in ADA with a fiat reference, fees explained inline
• Status copy written from the user's view, not the chain's

Lender and borrower were forced through the same screens

• A single flow tried to serve both sides of the deal
• Each person saw actions that weren't theirs to take
• Confusion over "whose turn is it" stalled deals mid-flow

Split the journey by role and turn

• Each party sees only their next action
• A clear "waiting on the other party" state for the off-turn side
• Notifications nudge the right person at the right step

New users had to risk real ADA to understand the product

• The only way in was a funded mainnet wallet
• High stakes for a first run of an unfamiliar concept
• Drop-off before anyone reached the self-settling "aha"

A demo wallet to learn the loop risk-free

• One-tap demo wallet, pre-funded with test ADA
• The full happy-path loan runs before real money is involved
• The leap to a real wallet happens once trust is earned

People wanted any agreement, we could only safely ship a few

• Open-ended contracts meant unbounded edge cases
• Each new type multiplied states, copy and testing
• No way to guarantee safety on contracts we hadn't seen

Shipped a curated set of vetted templates

• Launched with loan and escrow only, tested end to end
• Closed off custom contracts despite clear demand
• Roadmapped a template gallery instead of an open builder

Network fees made a "free" agreement feel less clean

• Every on-chain action carried an unavoidable ADA fee
• Hiding it felt dishonest, showing it added friction
• Min-ADA rules confused people expecting exact amounts

Chose transparency over a frictionless illusion

• Fees surfaced before each confirm, with a one-line "why"
• A small buffer in balances so amounts never surprised
• A slightly heavier flow, in exchange for trust

Settlement isn't instant, but users expect app-speed

• Confirmations take real time on the chain
• A storyless spinner felt broken to app-trained users
• "Did it work?" anxiety at the high-stakes moment

Designed the wait instead of hiding it

• Optimistic UI shows intent immediately, then confirms
• Honest progress states narrate what the chain is doing
• "Settled" lags "submitted", and we said so plainly

Holding keys for users would have been far simpler

• Self-custody puts seed phrases and recovery on the user
• A custodial model would remove the scariest steps
• But it betrays the whole point of a trustless agreement

Kept self-custody, softened the edges

• Stayed non-custodial despite the easier path
• Invested in clearer key and recovery education in-flow
• Higher onboarding effort, in exchange for real control

The IDE assumed everyone wanted to write Marlowe by hand

• The first cut centred a raw Marlowe code editor
• Non-Haskell developers bounced off the syntax
• The "anyone can build a contract" promise stayed theoretical

Multiple linked views onto one contract

• Added Blockly so logic is assembled, not typed
• Code and blocks stay in sync, edit either side
• Lowered the floor without lowering the ceiling

Marlowe, Blockly and Flow each competed for the canvas

• A third "Flow" diagram sounded helpful on paper
• In testing it duplicated Blockly without adding clarity
• Three synced representations tripled the build cost

Cut Flow, doubled down on Marlowe and Blockly

• Dropped the Flow view before it shipped
• Put the effort into two views that are genuinely reliable
• A simpler model: read it, or build it

The only way to see behaviour was to deploy and watch

• The early flow pushed contracts on-chain just to observe them
• A slow, costly loop for something you repeat constantly
• Mistakes only surfaced after real deployment

A step-by-step simulator inside the IDE

• Simulate the contract as the consumer would experience it
• Step through deposits, choices and payouts before publishing
• Catch logic errors in seconds, not on-chain

Invalid contracts failed without saying why

• A bad contract simply refused to run
• Errors pointed at internals, not the line you wrote
• Developers couldn't tell a typo from a logic flaw

Errors and warnings that point at the cause

• Syntax errors surfaced inline at the offending line
• Warnings flag risky-but-valid choices before simulating
• The simulator halts loudly and explains what broke

A cloud IDE can't match a full local dev setup

• Serious devs expect their own editor, plugins and shell
• The browser sandbox limits what we can offer
• Heavy contracts strain an in-tab environment

Optimised for the first contract, not the thousandth

• Prioritised zero-setup onboarding over pro-grade depth
• Accepted a ceiling on advanced local workflows
• Bet that "open a tab and start" wins more people in

Safer contracts meant fewer ways to write them

• Constraining the language prevents whole classes of bug
• It also blocks clever, valid patterns devs might want
• Marlowe's safety is both the point and the limitation

Kept the guardrails, made them legible

• Leaned into Marlowe's bounded, analysable design
• Explained why a pattern isn't allowed, not just that it isn't
• Less expressiveness, in exchange for provable safety

A contract branches more ways than anyone can click through

• Simulating one journey proves it runs, not that it's correct
• Walking every branch is overwhelming in a UI
• False confidence if people test only the happy path

Made the happy path easy, flagged the rest

• Designed a fast, clear single-path simulation
• Surfaced static-analysis warnings for unhandled cases
• Full verification lives beyond the simulator, and we said so

Marlowe itself was still evolving under the IDE

• Building UI on a spec that kept changing
• Polish risked becoming rework on the next language shift
• Waiting for stability meant shipping nothing

Shipped against a moving target, kept it modular

• Released early to learn from real authors
• Kept views loosely coupled so language changes stayed contained
• Ongoing churn, accepted as the cost of being first