Platform architecture & enterprise systems

Realtime developer infrastructure in two concepts

Sim developer platform

Developers needed realtime, account-centric data; Dune was built for analysts writing SQL. The MVP had three months, no clear customer profile, and engineers waiting to build.

Sim is Dune's realtime API platform for developers building wallets and apps. I designed its first developer portal, from sign-up and onboarding to usage-based billing for self-serve and enterprise customers, and it shipped on time. It then grew into Sim IDX (June 2025), an indexing layer built on technology from smlXL's sim.studio, where developers wrote logic that ran inside the EVM as each block executed.

1 Home2 Apps3 App4 Endpoint5 Failed preview

1. Use design to force clarity. Engineering and product had strong, conflicting opinions. I used structured user flows to make the gray areas visible and ran short daily sessions with Shane, Sim's lead PM, one open question at a time, until the scope could ship.
2. Reduce it to two concepts. Developers learned only listeners, which write onchain activity to a managed Postgres database, and APIs, which read from it. Provisioning, backfills, and schema were the platform's job.
3. Fit the loop developers already have. Connect GitHub and push: every commit to main deploys and every pull request previews. The portal made that pipeline legible: what's live, how far each chain has backfilled, and which routes are ready to test.
4. Know what didn't work. Sim IDX had real customers but was niche, expensive to maintain, and couldn't add chains fast enough, so Dune ended the beta six months after launch. The lesson I carry: a powerful capability isn't the same as a product, and the earlier design names the customer, the cheaper that answer is.

Outcome The portal shipped on time, about three months from zero. When Sim IDX ended, Dune refocused on the Sim APIs the portal was first designed for.

SourcesLaunch post · Demo video · Sunset post

Enterprise governance, without losing the community

The organization layer

Nine enterprise deals depended on org governance that didn't exist yet. I had about a month to go from zero to shipped.

Coinbase had three disconnected enterprise plans. User and team accounts were treated as one thing, people spent credits from the wrong account, and every governance question was a support ticket. The real question: how should identity, ownership, and execution relate in a product that started social and was becoming enterprise?

Enterprise adminEnterprise memberPlus plan teamPersonal account

1. People get credit, teams pay, objects execute. I compared six products' account models (Figma's team, GitHub's user, Vercel's project) to make Dune's ambiguity legible. We chose a hybrid: execution like Vercel, attribution like GitHub, so enterprise teams got control and the community kept its reputation.
2. Make high-impact context explicit, not global. Only a few actions need context: running queries, publishing private content, managing permissions. Those now say whose resources they use; everywhere else, context gets out of the way.
3. Design for the ideal, ship the possible. Research surfaced a deeper user and team conflation. With deals on the line, we designed around it, shipped the simplest switcher that kept every team visible, and documented the ideal as the brief for the follow-on work.

Zero to shipped

~1 month

Enterprise accounts migrated, day one

11

Deals unblocked

9

Shipped issues

27, across 4 milestones

Outcome I designed the switcher, roles, settings, and usage and billing across four plan states. Eleven enterprise teams moved into organizations on day one, SSO and two-factor moved out of support tickets and into the product, and the nine contracts that were waiting on org governance were unblocked, including Coinbase, Ripple, and Arbitrum.

Helping people find data they can trust

Data catalog & search

130+ chains, thousands of tables, and two teams with two different answers. Neither knew the other was working on the same problem.

Data engineering saw an information architecture problem: people couldn't find dex.trades in a taxonomy built around Dune's internals. Growth saw a discovery problem: enterprise users arrived with a use case, not a dataset name, and fewer than 5% found anything meaningful through Discover. Both were right, and solved separately they would have shipped two retrofits with no shared logic.

1. CuratedPre-built cross-chain datasets, grouped by use case: DEX trading, stablecoins, prediction markets.
2. Chains
3. Protocols
4. My data
5. Community

Open Dex Trades

1. Search, not Discover. Growth wanted trusted content in the Discover feed, but reshaping a community feed for enterprise would change it for everyone. Search already spanned the product, so 14 use cases from research became 4 jobs and the tabs on Search Home: one investment that served both teams.
2. Rebuild from how users think. A faceted tree organized around users' mental models replaced the folder structure, and search results grouped the same way.
3. Signal trust honestly. Enterprise users judge data by who maintains it, so Enterprise, Curated, and Protocol-maintained labels replaced editor's picks. I steered away from a Verified badge, which would imply Dune vets content it doesn't.

Daily searches, 30 days

~1,700 → 35,000

Before

After

Table insertions

3× (8% → 30%)

8%

30%

Search click-through

+131%

Outcome One architectural decision made two teams' requests redundant, and search became one of the highest-traffic surfaces in the product.

Starting from working code, not a spec

Designing in the codebase

Complex, backend-heavy changes still meant long specs, long handoffs, and drift between what design intended and what shipped.

In Q1 2026 I shipped 65+ production features and changes myself. The number isn't the point: for complex, backend-heavy work, I started a new loop with engineering, and it became how we worked together.

1. Prototype the change, not the screen. I used Claude to prototype the actual change in the codebase, so the conversation with engineering started from working code instead of a spec.
2. Review together, tweak live. We reviewed the prototype side by side and adjusted it in real time, settling in minutes what used to take rounds of comments.
3. Hand off, then take it back. Engineers took a pass and did the backend work, then I took it back for the final polish. Design owned the experience end to end without owning every line.

Shipped myself, Q1 2026

65+

Outcome Fewer handoffs, less drift, and a working model for complex changes that didn't depend on a perfect spec up front.