A browser phone OS drawn entirely on a single p5.js canvas - a live lock screen, a generated-notification engine, gestures, a passcode flow, and hidden camera modes, all coordinated on one shared coordinate system.
Product screens
The page diagrams its own build - page shell, p5.js renderer, state modules, and notification generators.
A per-source engine fills the lock screen with varied, in-character alerts on every visit.
The status bar, notification cards, and phone frame are all drawn on a single p5.js canvas.
A per-source engine fills the lock screen with varied, in-character alerts on every visit.
The page diagrams its own build - page shell, p5.js renderer, state modules, and notification generators.
The status bar, notification cards, and phone frame are all drawn on a single p5.js canvas.
The strongest signal first, then the operating context around it.
Build Narrative
Most web interfaces are assembled from DOM elements and someone else's component library, which quietly hides how rendering, input, and state actually fit together. I wanted a build where none of that was given - where every pixel, gesture, and state transition had to be designed and coordinated by hand.
DylanOS is a fake phone, built way too seriously. A React page shell loads a client-side p5.js renderer that draws the entire phone - status bar, notifications, quick settings, passcode pad, fake home screen, and camera - onto one canvas. A notification engine generates in-character alerts from dozens of fictional app sources, and a single input layer routes mouse, touch, drag, swipe, and keyboard into the simulation.
A polished, self-contained browser toy that doubles as a front-end engineering case study - proof of comfort with canvas rendering, input systems, and generated content, and of shipping quickly with AI assistance.
Framing
It is deliberately not a component library or a real operating system. It is a showpiece for a specific kind of front-end work - coordinating rendering, generated content, state, and input on a canvas - and for shipping something polished quickly with an AI coding assistant. I split the simulation into clear responsibilities - drawing, input, state, notifications, quick settings, passcode, fake OS, and camera - and kept one internal coordinate system for the phone. The notification generators are organized by source category so the feed feels alive, and the render loop pauses itself when the phone is not visible.
Systems Index
Key features in scope
Role and product posture
Engineering
DylanOS is a fake phone, built way too seriously. A React page shell loads a client-side p5.js renderer that draws the entire phone - status bar, notifications, quick settings, passcode pad, fake home screen, and camera - onto one canvas. A notification engine generates in-character alerts from dozens of fictional app sources, and a single input layer routes mouse, touch, drag, swipe, and keyboard into the simulation.
Systems Index
Architecture choices
Key decisions
Hardening
A polished, self-contained browser toy that doubles as a front-end engineering case study - proof of comfort with canvas rendering, input systems, and generated content, and of shipping quickly with AI assistance.
Systems Index
Results after shipping
Constraints
Lessons
Rendering a full UI on a canvas trades CSS layout for total control - and makes you build hit-testing, focus, and accessibility yourself
A generator-per-source model keeps synthetic content feeling varied far better than a static list
Small performance guards - off-screen pause, asset preloading - matter a lot for an interface that never stops drawing
Explaining the architecture on the page itself turns a toy into a credible case study
Retrospective
With more time I would separate the state boundaries further before exposing any public API, bring the canvas UI closer to full DOM-equivalent screen-reader semantics, and replace manual regression checks with an automated browser-interaction test suite.
AI / Workflow Tooling
A schema-aware Airtable diagnostics app that scores base health, surfaces structural and workflow issues, and turns the detected model into dashboards, forms, portals, and migration-ready redesign artifacts.
Read case study
Digital Platform / AI
A unified platform for a naturopathic doctor - book, blog, and podcast in one place, with a RAG assistant that answers questions from her published work and cites its sources.
Read case study
AI / RAG
A Socratic dialogue platform where Plato and Socrates debate you across five dialogue modes, with every response grounded in the primary texts and backed by visible source citations.
Read case study
AI / Social Product
A social network where AI-generated bot accounts could post, react, and interact in realistic feed dynamics.
Read case study
