CoinFello
Built the design system and implemented it in code. A DeFi product with an AI agent at the centre of it.
What I can showEmployed work under NDA. What I can show is the design system itself — components with placeholder content — and the public site. No product screens, no customer data, no internal numbers.
- Role
- Front-end Developer — design system owner
- Team
- Distributed team — US, Europe and LATAM
- Timeline
- 1 year 3 months
- Platforms
- Web
- Stack
- TypeScript, React, Tailwind CSS, Design tokens, AI tooling
CoinFello is a DeFi agent: it answers questions about assets and protocols, executes swaps and staking, and runs recurring strategies inside limits the user sets.
I joined as a front-end developer and built the design system: tokens, components and conventions. There was nothing to inherit. Then I implemented it in code.
This is also where I started using AI daily, after the system existed and I already knew what good looked like in the codebase.
Keep a product that ships features every day consistent — in its components, its behaviour and its layout at every screen size.
- Features shipped daily
- Tablet and mobile had to work on everything, not just desktop
- I designed the components and implemented them, so there was no hand-off to catch mistakes
Scope, in my own words.
Built the design system
Token architecture, component library and the conventions that keep an interface coherent while several people change it at once.
Implemented it in code
I wrote the system rather than specifying it. 55 components, built in React and Tailwind on top of Mantine.
Used AI deliberately
I use AI daily and review everything it produces the way I would review a junior's pull request. It handles scaffolding, migrations and repetitive variants.
Problem, decision, and why it was the right trade.
Consistency had to be structural, not reviewed
- Problem
- We released features every day. At that pace an interface cannot be kept consistent by reviewing screens — something always ships before anyone looks at it.
- Decision
- I built the design system so the component is the fastest way to build a screen, and implemented every component myself.
- Why it held
- When using the system is less work than going around it, consistency stops depending on anyone remembering.
Responsiveness in the component, not the page
- Problem
- Every feature had to work on tablet and mobile, and features arrived faster than anyone could retrofit layouts.
- Decision
- Each component handles its own breakpoints, so a screen assembled from components is responsive before anyone thinks about it.
- Why it held
- It moves the work to the place it is done once instead of the place it is done every time.
I implemented what I designed
- Problem
- A design system described in a file and a design system in the codebase drift apart, and nobody notices until a screen looks wrong.
- Decision
- I owned both ends: the components in the file and the components in the app were the same work.
- Why it held
- There was no specification to interpret, so there was nothing to interpret differently.
The system in production
The product is public. The yellow on the Launch app button is the same token as the yellow on the chip and the button in the files above.
I wrote production front-end by hand for a year at HyperPlay before I used AI for any of it. I work either way.
- Components, ready for dev
- 55
- Components I designed and built
- 55
- Duration
- 1y 3m
HyperPlay
Three and a half years on a web3 game launcher. Product design and research in the design team, then front-end work on the same interface in the engineering team.