I build product-focused frontend software.
Selected work across operational software, frontend systems, AI interfaces, and polished production implementation.
- Frontend: React, Next.js, TypeScript, Tailwind
- Systems: Storybook, Orval, TanStack React Query, Zustand
- Delivery: GitHub Actions, Playwright E2E, AWS, PHP
- Creative: Framer Motion, Three.js / React Three Fiber
Operational software for scheduling, staffing, and day-to-day execution.
Ordio is software for operational teams, where speed, clarity, and reliability matter more than decorative UI. I worked on the frontend across workforce and scheduling workflows, while collaborating closely with the platform’s AWS infrastructure and PHP-based backend.
Problem and constraints
- Operational users needed fast, readable interfaces for scheduling and workforce coordination
- UI decisions had to hold up under dense business data and state-heavy workflows
- Frontend work had to align with an existing PHP platform and AWS-backed infrastructure
- Reliability and workflow clarity mattered more than visual novelty
What I contributed
- Built product-facing frontend flows around staffing, scheduling, and operational actions
- Translated complex platform rules into interfaces that stayed usable under real business constraints
- Worked across frontend delivery while coordinating with backend and infrastructure concerns
- Focused implementation on clarity, speed, and reduced friction in repeated internal workflows
Reusable product UI patterns backed by a documented frontend system.
For REMONDIS Neos, I worked across UX structure, product UI, and reusable implementation. The goal was not only to ship screens, but to define patterns that could be reused consistently through a shared component library and clearer frontend conventions.
System work
- Defined reusable UI patterns instead of treating each screen as a one-off build
- Used Storybook to support documentation, shared language, and more predictable implementation
- Built for consistency across forms, layout structure, feedback states, and repeated product flows
- Turned product decisions into reusable frontend building blocks
What that changed
- Reduced duplication across product screens through shared components and conventions
- Made UI decisions easier to repeat and extend as the product grew
- Connected UX thinking directly to production code rather than static mockups alone
- Positioned the work as a frontend system, not just a collection of isolated screens
AI psychotherapy simulator with streaming chat, voice features, and durable session state.
RawTherapy combines frontend interaction design with AI implementation: patient-based simulation, prompt construction, streaming responses, voice input and output, and session persistence. I chose backend-controlled conversation state over client-side state so sessions would stay consistent across reconnects, retries, and long-running usage.
Product and technical challenge
- The interface had to feel conversational and responsive while managing long-lived session state
- Streaming text, voice input, voice output, and AI orchestration had to work as one product flow
- Retries and reconnects could not create broken or duplicated session history
- The system needed durable persistence rather than purely local conversation state
Key decision
- Kept conversation state on the backend instead of relying on the client as the source of truth
- Used backend rules, locking, and persistence to support idempotent flows
- Built the frontend around streaming updates and active-session feedback
- Connected prompt construction, session storage, and UI behavior into one consistent interaction model
Campaign frontend with restrained motion and premium visual pacing.
A marketing-oriented web experience centered on imagery, brand presentation, and polished storytelling. This project shows a different side of my frontend work: careful layout, visual hierarchy, responsiveness, and restraint rather than application complexity.
What mattered here
- Image-led storytelling with clear hierarchy across sections
- Responsive layout decisions that preserved the campaign’s visual rhythm
- Brand-sensitive implementation without overdesigning the interaction
- High-fidelity execution where pacing and restraint carried the experience
Why it is included
- Shows frontend range beyond dashboards and system-driven product UI
- Demonstrates polish in spacing, imagery, and presentation details
- Supports the visual side of my engineering profile
- Balances the more operational and architecture-heavy case studies above
This site — a personal portfolio built as an immersive frontend system.
I built this site itself as both portfolio and implementation surface: editorial navigation, image-led storytelling, motion, route-level presentation choices, and experimental frontend techniques on Next.js 15, React 19, Framer Motion, and Three.js.
Built into the site
- Route-level presentation choices for different navigation modes and page moods
- Gallery structure and project-specific image systems
- Motion-led transitions and immersive framing
- Editorial pacing across image-heavy project pages
Purpose
- Acts as both portfolio and working frontend experiment
- Shows how I handle presentation systems as well as product systems
- Connects visual direction directly to implementation detail
- Rounds out the portfolio with creative and technical authorship in one place
What this range shows about how I work.
Product workflows
On Ordio and RawTherapy, the work is centered on flows that need to stay clear under operational complexity, session state, and repeated user actions.
Frontend systems
On REMONDIS Neos, I treated the interface as a reusable system: shared patterns, documented components, and implementation choices that could scale beyond one screen.
Technical range
My frontend work regularly touches delivery pipelines, testing, cloud infrastructure, backend integration, and state architecture — not only surface-level UI.
Visual control
Projects like Leica and this portfolio show that engineering depth and visual restraint can coexist without one weakening the other.
I care most about turning product requirements, interface decisions, and technical constraints into frontend work that still feels clear and well-made.