I designed Odisei Play for 17 months. Then I moved into the codebase and shipped the screens myself, on web, iOS and Android.

Odisei Play, Songs on iPhone
ClientOdisei MusicElectronic saxophone, Barcelona
RoleDesign engineerproduct designer before that
Duration2 yearsincl. 6 months in the code
StackReact NativeExpo, Storybook, Claude Code

For 17 months I drew screens in Figma, and a developer rebuilt them in code. That handoff is where the product lost quality.

  1. Made twice

    Once in Figma, once again in code.

  2. Cut at build time

    Gradients, SVG effects, textures: dropped weeks later, when the framework said no.

  3. Endless corrections

    Every review round cost two people a day. There was always another one.

Same repo, same stack, same code reviews as the developers. And I already knew every screen by heart.

17 months, designing in Figma
6 months, building it
Oct 2024March 2026today

  • One codebase, three screens

    Web, phone and tablet, from the same code.

    React Native, Expo
  • One styling system

    Type, colours and spacing from one source.

    NativeWind, tokens
  • Animation with feeling

    Celebrations, the wheel, the playing views.

    Reanimated, Skia
  • The team’s workflow

    Branches, pull requests, reviewed by the lead dev.

    Git, code review
  • The handmade look

    Raised buttons, carved text, neon glow, right on every device.

    Odisei’s signature

The repo was set up for AI agents. I built every piece in Storybook first, and the CI checked it everywhere.

The rule

iPhone 16
StreakCelebration/Default
181 stories built this way

A mistake caught once becomes a rule Claude Code follows from then on.

  1. caught in reviewA new card styled from scratch
    now a ruleLook for a component that already does it, and reuse it
  2. caught in reviewText set in the old typeface
    now a ruleAll new text uses the brand typeface, only the weight changes
  3. caught in reviewA screen story with a white frame around it
    now a ruleScreen stories fill the whole canvas and clear the status bar
  4. caught in reviewA toggle on web that switched itself back off
    now a ruleSounds fire on press-in, toggles fire on press, everywhere

40+
releases to productionweb, server and app, together
190
pieces in the shared librarybuilt and documented by me
0
mockups handed over to be rebuilt
Odisei Play in real-world use

Seven files out of ten were that shared library, the one every screen is built from.

home
onboarding
songs
practice
streaks
courses
70%the shared librarybuilt once, reused by every screen above
30%code for one screen only
Where my work landed, across everything I touched in six months.

01

Onboarding

The full welcome flow, Bluetooth pairing included, with the paywall moved after the first session.

02

The public website

Rebuilt from one giant file into sixty reusable blocks.

03

Progress and rewards

Streaks, goals, badges, and animated celebration screens in portrait and landscape.

04

The reward wheel

Haptics and sound synced to how fast the wheel really turns.

05

Public course pages

Course pages outside the app, so people find Odisei through search.

  1. 01No duplicates

    If something close exists, I extend it instead of writing it again.

  2. 02One source of truth

    No value typed by hand, so screens can’t drift apart.

  3. 03Nothing thrown over a wall

    Developers plug in a finished, reviewed piece. They rebuild nothing.

One person, one build, no correction loop. Your developers get their week back, and your users see the design you agreed on.

Let’s talk.

One person, from the first sketch to the shipped screen.

© 2026 santos studio · Léa Santoscase study · odisei play
Book a call