React engineering for product interfaces
React is my strongest implementation layer. I use it to build product workflows, not isolated screens: clear state boundaries, reusable interaction patterns, accessible behavior, and components that can support the next related feature.
- Component boundaries shaped around product behavior
- TypeScript APIs that make valid states easier to express
- Server and client boundaries chosen for the actual interaction
- Loading, error, empty, permission, and responsive states
- Keyboard, focus, semantic, and reduced-motion behavior
- Performance work tied to the route and user journey
Where this capability shows up in the work.
- 2025CVLeap AI: multi-step product workflowConnected onboarding, account state, an AI-assisted editor, storage, and PDF export in a Next.js and TypeScript product.ReactNext.jsTypeScriptSupabase
- 2024I AM ART: scroll-led photography portfolioCombined image transitions, lazy loading, and a preload queue so a motion-heavy concept remained usable across screen sizes.JavaScriptGSAPLocomotiveShery.js
- 2024Last 3 Feet: reusable marketing-site sectionsShipped a React and Tailwind site in five days with reusable sections and a recorded Lighthouse score of 98.ReactTypeScriptTailwind
A maintainable frontend makes product changes local and understandable.
I look for boundaries that match the product: which state belongs to a route, a workflow, or a reusable component, and which behavior needs to remain visible to the feature using it.
The business effect is straightforward. When common behavior has a clear home, adding a related workflow involves less duplicated code and fewer regressions across existing screens.
Scope, evidence, and how I apply this work.
Are you primarily a React developer?
React and Next.js are my strongest technical tools, but my primary positioning is product engineer. I use frontend expertise together with product and interaction judgment rather than treating implementation as a separate handoff.
Can you work in an existing React application?
Yes. I start by learning the current component, state, data, and testing patterns, then make the smallest architectural changes needed for the feature instead of imposing a new stack.
How do you decide what becomes a shared component?
I share repeated behavior and stable interface rules. I keep product-specific differences explicit until there is evidence that the abstraction will make the next change easier.
Do you handle accessibility and performance?
Yes, in the context of the actual interface. I cover semantic structure, keyboard and focus behavior, reduced motion, loading behavior, bundle boundaries, and route-specific performance issues.
Tell me where the workflow is stuck.
Share the product, the people using it, and what needs to become easier or faster. I will tell you whether my product and frontend experience fits the problem.