Ninety Days to an AI-Native DeFi Platform

Snapshot

The challenge

The client arrived with a bold thesis and a blank page: DeFi is fragmented across trading, lending, and derivatives, and the next generation of users — including autonomous AI agents — will need a single account layer, a unified view of their assets, and a natural-language way to act on them.

That's a great vision and a terrible spec. On day one we had no agreed architecture, no scope boundary, three client stakeholders with three different mental models of the product, and a hard expectation of a working MVP in roughly ninety days. Midway through, a fresh piece of US regulatory guidance landed squarely on our roadmap, and late in the engagement the client's broader corporate strategy shifted underneath us.

This case study is about the product management system that kept the build on track through all of it.

Move 1 — A discovery phase with an exit condition

Instead of jumping into sprints, I ran a short, deliberately bounded discovery phase with one exit criterion: a signed architecture and statement of work that all client stakeholders had actually read.

The mechanics were simple but disciplined:

• Structured stakeholder interviews, one per client lead, capturing not just requirements but each person's model of the product — which is where the contradictions live.
• A document register and a single source of truth. Every artifact got a canonical location and a status (draft, superseded, signed). When a client executive quoted a six-week-old draft in a call, we could resolve it in seconds instead of relitigating scope.
• Decision logging. Every "we'll go with X" from a call was written down with its date and rationale, so decisions survived personnel changes — which turned out to matter more than expected.

Discovery converged in weeks, not months, because it had a defined finish line rather than a vibe of "we'll start building when it feels ready."

Move 2 — A working prototype as the alignment tool

The product's core promise — type an instruction in plain language, get a compiled, simulated, executable DeFi transaction — is exactly the kind of thing that slide decks flatten and demos sell.

So early in the engagement I stood up a hosted mock API implementing the full intent flow (parse → compile → simulate → confirm → execute) against simulated venues, plus a small demo front-end wired to it. No real funds, no real chain dependencies — but a real request/response contract.

This did three jobs at once:

1. Executive alignment. Client leadership could feel the agent experience months before mainnet, which ended debates that documents never would have.
2. An integration contract. Front-end and back-end teams built against the mock's schema, so the real API slotted in behind it rather than triggering a rewrite.
3. A safe playground for the AI lead on the client side to pressure-test agent behaviors without touching production anything.

The lesson I keep re-learning: for agentic products, a clickable prototype isn't a nice-to-have — it's the only shared language the whole room speaks.

Move 3 — Treating regulation as a product workstream, not a legal footnote

Mid-project, new regulatory guidance from a US authority redrew the boundaries of what a compliant DeFi interface could do. Many teams would have parked this with lawyers and kept building.

Instead, I ran a feature-by-feature collision analysis: every roadmap item mapped against the guidance's conditions, with a verdict — compliant, remediable, or fundamentally in conflict. That analysis surfaced hard truths early: one entire vertical couldn't launch in the US market in its planned form, and a couple of revenue mechanics conflicted with the safe-harbor conditions.

The output wasn't a memo; it was a scope decision. The client narrowed V1 to the compliant core, the conflicting vertical moved behind a geographic boundary, and remediation items became a priced extension track rather than silent scope creep. When the client's external counsel later delivered their formal opinion, it validated the direction we'd already engineered toward — meaning zero rework.

I also made one standing rule for myself: every AI-agent feature proposal got checked against the legal analysis before it reached engineering. In an agentic financial product, "the model might phrase this as advice" is a compliance bug, not a UX nit.

Move 4 — Quality gates for the AI layer

An AI agent that executes financial transactions cannot ship on vibes. Working with the tech lead, we put structure around the agent:

• An evaluation suite wired into CI — behavioral regressions (including the "never gives financial advice" rule) fail the build, the same as a broken unit test.
• Telemetry before cleverness. We deferred sophisticated self-improvement machinery until there was real traffic to learn from, and instrumented first.
• A gate before externalization — no agent capability reached end users until it passed the eval bar.
• A clean proposal/build split. I owned proposing improvements in build-ready form — evidence, proposed fix, size estimate — and engineering owned building them. No half-specified "the agent should be smarter" tickets.

Move 5 — Cadence as the shock absorber

Over ninety days the engagement absorbed: a mid-project regulatory shift, a client-side strategy pivot, and personnel changes on both sides. What held it together was an almost boring operational layer:

• Two-week milestone sprints, fixed-price per milestone — every invoice tied to demonstrated, accepted output.
• A weekly checkpoint call with a standing agenda, and a demo every sprint without exception.
• The tracker synced to the build plan at PR-level granularity — fifty-plus pull requests across two sprints each attributed to a plan item, so "what did we get for this milestone" was a query, not a negotiation.
• A lightweight client portal with per-sprint architecture visuals, refreshed on a repeatable pipeline, so non-technical stakeholders always had a current picture.

When the client's strategy pivoted late in the engagement, this paper trail is what made the conversation calm: scope, spend, and delivered value were all legible at a glance.

Results

• All product verticals live on testnet roughly two-thirds of the way through the timeline — the bottleneck moved from engineering to external dependencies (audit, legal), which is where you want it.
• A working demo every two weeks, for every sprint, including a unified front-end demo for client leadership.
• The MVP scope survived two external shocks — a regulatory redraw and a corporate strategy pivot — without a rebaseline.
• A priced post-MVP extension catalogue (compliance remediation, hardening, infrastructure, new verticals) that converted "out of scope" from a rejection into a pipeline.
• Zero compliance rework when formal legal opinion arrived, because the roadmap had already been engineered against the guidance.

What I'd tell other PMs

1. Give discovery an exit criterion. A discovery phase that can't end is just expensive anxiety.
2. For agentic products, prototype the conversation, not the screens. The intent flow is the product; mock it end-to-end first.
3. Read the regulation yourself. Then translate it into a feature-level verdict table. Lawyers tell you what's risky; only the PM can tell you what to cut.
4. Evals are the new acceptance criteria. If an AI behavior matters, it should be able to fail a build.
5. Boring cadence buys you the right to survive chaos. Demos, decision logs, and PR-level traceability feel like overhead — until the week they're the only thing holding client trust together.

Written by João Capinha, Product Manager. Specific names, figures, and commercial terms omitted in accordance with confidentiality obligations.