0→1 developer tooling & AI workflows
Two products, one runway, zero playbook: founding designer at an a16z- and Greylock-backed startup building developer infrastructure for blockchain data.
- 2 mo to an investor-ready alpha
- 600+ sign-ups, from 100+ organizations and independent developers
- 20 → 50% AI execution completion
- 20K+ monthly developers
- Acquired by Dune
What I owned
- LedProduct model & scope
- Ledsim.studio
- LedAI workflow assistant
- Ledsim.explorer
Scope
- 1st
- designer
- 9
- engineers, plus a founder and PM
- Seed
- stage runway
What lasted
The product architecture, separate schemas and lambdas on a graph canvas, held through a change of transformation language without rework, and its technology became the foundation for Sim IDX at Dune.
The structural problem
How do you design the mental model for a system that has never existed, before you can design any UI at all?
Building on blockchain data meant stitching together fragmented, hard-to-index sources with custom infrastructure. smlXL built a backend that removed that burden.
As the first designer, my job wasn't choosing components. It was deciding how a developer should think about the system: where the interface abstracts, where it exposes, and which decisions lock you in. All on seed-stage runway.
The work
The studio made it a product. The assistant made it approachable. The explorer, built first to prove the backend, found its own audience.
A whole data pipeline on one canvas
sim.studio
Two months to an investor-ready alpha, in a product category with no precedent to copy.
Building on realtime blockchain data meant stitching together node providers, indexers, and ETL by hand, and power users couldn't keep complex workflows in their heads. sim.studio put the whole pipeline on one canvas under one principle: streamline complexity without sacrificing power.
“sim by smlXL is how blockchain data should have worked from the start. Instead of writing boilerplate code to parse events, calldata and traces we can focus on correctly implementing logic.”
- Decide by the cost of being wrong. Every feature faced three questions: could the back end support it in time, did an end-to-end flow need it, and how much would we undo if we were wrong. The last one drove most calls, like keeping schemas and lambdas separate.
- Test the interface, don't assume it. The instinct was IDE-first. I pulled engineers into research and we role-played the same tasks in an IDE and a visual UI. The UI was faster and less error-prone, so it shipped first; both direct competitors later went UI-first too.
- From a pipeline to a graph. Real use cases didn't need a fixed order, so the canvas became a directed graph where data could branch and merge.
- Power first, then approachability. The EVM Lambda, our most powerful component, was also the biggest drop-off. I tested three directions and focused the flow on the task, which lowered drop-off, and the next question, “what hooks do I add?”, led to the AI assistant.
- Alpha shipped in
- 2 months
- Closed alpha
- 50 developers
- Organizations adopted
- 100+
- Sign-ups, incl. independent developers
- 600+
Outcome Shipped on time to a closed alpha of about 50 developers. Our PM rebuilt sim.explorer's modules on the canvas in under an hour with no back-end engineer, and the architecture held through a change of language and into the Dune acquisition.
Plain-language goals, code developers stay in control of
AI workflow assistant (simAI)
Developers knew what they wanted to build. They didn't know which hooks, transforms, and code would get them there.
Templates helped developers who knew which hooks they needed; most didn't. The assistant turns a plain-language goal into data transformations and code. A wrong transform quietly corrupts data downstream, so the question wasn't how to generate code but how a developer could trust code they didn't write.
- Flip the flow. I backtracked our most-used hooks to semantic actions, so developers start from what they want to happen and simAI suggests the hooks and code.
- Reviewable and editable. Every generated step shows before it runs and can be changed in place. The assistant drafts; the developer decides.
- Same trust problem, new source. At Chainalysis the uncertain source was people; here it was a model. The answer rhymed: show where output came from, keep it inspectable, and make correcting it cheaper than starting over.
- Users
- 600
- Execution completion
- 20% → 50%
Outcome Execution completion went from 20% to 50% across 600 users, with less hand-holding from our team. The lesson I carry into AI products: the model drafts, the interface earns the trust.
The dogfood that became a product
sim.explorer
Block explorers show balances and gas fees. Developers debugging smart contracts need what's underneath.
A block explorer is search for a blockchain: any transaction, wallet, or contract. Ours was built to dogfood smlXL's backend, and it stayed because developers kept using it.
- Go below the surface. I focused the explorer on contract storage (the variables a contract actually manages, like balances, ownership, and paused flags), which mainstream explorers didn't expose.
- A tree for the transaction tracer. I compared a linear call stack, a tree, and a timeline. Users' main job was debugging nested calls, so the tree won, with key data types highlighted to show where to look.
- Overview first, detail on demand, on any screen. A row view summarizes the trace and tabs open the detail. With 41% of users on mobile, it became the first explorer with a mobile tracer.
- Monthly active developers
- 20,000+
- Users on mobile
- 41%
Outcome It proved the backend. Then, under runway pressure, I helped pivot the company from an explorer to developer infrastructure.