Cookie PRO: designing pro-grade crypto analytics, from sketch to production code

Problem

Turn Cookie's vast, dense crypto dataset into a professional analytics surface that works for two audiences at once — analysts who need efficient access to depth, and enterprises evaluating Cookie as a data provider — while the product direction was still being defined.

Solution

A layered architecture (curated insights first, raw data on demand) with pro-grade filtering built on Cookie's social data, in a professional visual language distinct from the consumer products. When Figma-to-handoff became the bottleneck, I pivoted to building the production frontend directly in code.

Outcome

A complete professional analytics surface built end-to-end — from sketch to vibe-coded production frontend — proving out a layered approach to dense data and a code-first process that collapsed the traditional design-to-build loop.

Context: what Cookie is

Cookie is a data infrastructure company in crypto. It collects and structures data that's otherwise hard to get at — sentiment, mindshare (our own scoring metric), on-chain activity, influence patterns. Effectively, the analytics layer for the whole crypto ecosystem.

That data fed four products:

• Cookie3 Analytics — social and blockchain analytics suite for enterprise crypto marketers
• cookie.fun — consumer-facing tracker for retail traders to spot trends and attention shifts
• Cookie Snaps — social marketing campaign platform connecting brands with content creators (the company's biggest revenue stream)
• Cookie PRO — the professional analytics layer for funds, researchers, and serious builders who need depth and density, not simplified retail views.

Same data underneath, four surfaces for four audiences. PRO was the most demanding of them, and the one that best shows how I actually work.

The real problem: breadth without drowning

Raw data on its own means nothing. Professional users want insights — but they also want the raw numbers one click away, the moment they need to verify or dig deeper. Cookie had an enormous amount of valuable data, and the hard part was showing that breadth without burying the person using it. Professional doesn't mean overwhelming. It means efficient access to depth when you need it.

But there was a second job the design had to do, and it shaped almost every density decision: PRO had to position Cookie as a serious data provider.

The primary purpose was to make the vastness and quality of our data tangible, so companies would plug into our API. Every screen was partly a sales argument — this is how much structured, crypto-native data we have, and this is how usable it is.

The secondary purpose was to give analysts and traders genuine insights they'd pay for and come back to. That split fed the business model directly: tiered pricing, with a free tier exposing basic market data as the top of the funnel.

So the design had to work on two levels at once — readable enough for a working analyst, impressive enough for an enterprise evaluating us as a partner. Balancing the working user against the evaluating buyer was the constraint behind most of what follows.

How I work: sketch → Figma → code

This is genuinely how the work starts for me. Rough sketches first, then straight into high-fidelity, then code.

Before I open any tool I sketch in Excalidraw — what belongs on each page, which filters apply, what each section is communicating, what the user is actually trying to decide. The decisions get made on paper. Figma is just where they get materialized.

I skip low-fidelity wireframes on purpose. With enough craft and an existing design system to lean on, I can go from a rough sketch straight to high-fidelity UI — designing in the real system, then adapting it to carry a more professional feel. The sketch carries the thinking; the design system carries the speed. Wireframes would just be a slower road to the same decisions.

So the evolution here isn't "wireframe → mockup → polish." It's rough sketch → high-fidelity in the inherited system → a re-thought professional direction → working code. Each step is a real shift in thinking, not a fidelity bump.

V1 — the inherited approach

The first iteration borrowed cookie.fun's design system. Path of least resistance — I built most screens on the foundation we already had.

It worked technically. But once I saw it built out as a rough frontend, the problem was obvious: the same visual weight as cookie.fun made PRO feel consumer-grade, when this product needed to feel professional. Different audiences need different design language, even inside the same product family.

V2 — a professional direction

I pulled from professional analytics tools — Coinglass, Token Terminal. Their patterns for advanced filtering, dense data, and analytics layouts mapped well to what we needed. Adapted, not copied: the heavier visual weight and information density gave PRO its own identity.

The key decision was a layered architecture — curated insights upfront, raw data reachable through drawers and expansions. Professional users don't want maximum density the moment they land. They want decision-relevant information first, with depth on demand.

Advanced filtering

This is where the Token Terminal influence went deepest — pro-level filtering built around our data structure: personas, audience targeting, geography, watchlists. The kind of depth retail products don't need.

I wanted the same filter set on every page, precisely because Cookie's social data applies to any project, sector, or narrative. You can build a custom feed of only the tweets that matter — "builders from Poland talking about this project." Who are they? What else do they talk about? That's where the real insight lives.

X wasn't built for crypto. So I designed the layer on top of it that makes that data actually useful for a crypto use case.

The vibe coding pivot

After V2 in Figma, iteration speed became the bottleneck. The traditional flow was killing us — design in Figma, hand off to the engineer, get a brittle frontend back, evaluate, find what didn't feel right, iterate. Painful, especially with the product direction still being defined.

So we pivoted. I started building directly in code — Claude Code in VS Code. The frontend engineer handled endpoints, data mapping, plumbing. I owned the UI layer — components, layouts, interactions, the "feel" part of UX.

Two things came out of it. The friction between design and engineering disappeared for the surface layer. And I could iterate the feel directly — animations, transitions, state — the things Figma can't really prototype.

Honest tradeoff: this only works when the designer can actually code. Most can't, so it's not a universal model. But for me it removed the single biggest bottleneck in the process.

(For context — vibe coding here means custom code in VS Code with Claude Code. Not Lovable or v0, which hand you templates with opinions already baked in, and not Cursor's autocomplete style. I prompt directly and build components from scratch.)

Working dashboard demo available on a call — happy to walk through it for relevant roles.

Reflection

Cookie PRO taught me exactly where Figma wins and where code wins. It wasn't my first time touching AI tools, but it was the first time I built a real product surface in code as the primary medium. The takeaway was less binary than people make it sound.

Once the vision is roughly defined, building in code is faster than mocking-and-handing-off — interactions, state, real data behavior, micro-interactions all land quicker in code than in a mockup loop. But early on, when the vision is still ambiguous, code is too slow. Figma wins there, for fast manipulation, system thinking, and cross-team review. Sometimes even rougher than Figma — Excalidraw or paper for the earliest calls.

The mistake I actively avoid is using one tool for everything. Ship and feel, rather than design and theorize — and use whichever tool gets you to "feeling it" fastest at each stage.