01 / interface · Product interfaces
Next.js and React developer for dashboards, admin panels and internal tools
The screens your customers and your team use all day. React, Next.js and TypeScript, built so the fortieth click is as fast as the first.
- React in production since 2022
- Sole engineer on a three-role platform
- Design-system primitives a frontend team builds on
what I build
Anything with a screen in front of it.
Two shapes cover most of it — a tool somebody has open for hours a day, and a page that has to arrive in under a second. Different jobs, different tools, same standard.
dashboards
the screen someone has open all day, where the second interaction decides everything
admin panels
internal tools for the people running the business rather than the customers
customer portals
the logged-in half of your product, where your customers do their own work
data-heavy tables
thousands of rows that filter, sort and page without the screen locking up
AI product interfaces
streaming answers with their sources beside them, and a real state for when the model is wrong
onboarding flows
the sequence between signing up and the first useful thing happening
design systems
the component library that stops a fourth engineer inventing a fifth button
marketing sites
static and fast, with no framework shipped to the browser to render text
how it goes
Idea, interface, product.
Four steps, in this order. The expensive mistakes all happen when one of them is skipped.
understand
who uses the screen, what they are trying to finish, and where the current one loses them
shape
information architecture and interaction patterns, decided before anything is drawn
build
React, Next.js and TypeScript in strict mode, on top of a component system rather than beside one
ship
deployed and measured — bundle size, Core Web Vitals, contrast, and every path a keyboard takes
why react
React is not the point. What it lets me promise is.
A framework is a means of making guarantees. These are the ones worth having, and they are the reason the fourth screen costs less than the first.
- reusable components
- one button, one source. Your fourth screen becomes assembly rather than invention.
- state you can reason about
- an order that is both paid and unpaid stops being a bug when the type refuses to let it exist.
- interaction that keeps up
- filters that respond while your hand is still on the mouse, at row one and at row four thousand.
- server-first data
- data that lives on the server is fetched there, so the browser downloads a page instead of a program.
- real-time surfaces
- streams, subscriptions and optimistic updates, without the screen ever telling someone a comfortable lie.
- architecture that survives
- boundaries still findable in month nine, when the person editing them is not me.
the problems I solve
You have probably said one of these out loud.
“The app works, but it feels terrible to use.”
Almost always a state and data-fetching problem wearing a visual disguise. I fix the interaction first, then the surface.
“The UI is becoming impossible to maintain.”
Five buttons, three of them nearly identical, and none safe to change. I collapse them into one component system with every state drawn.
“The dashboard is a pile of components nobody owns.”
I restructure it around the few patterns that actually repeat, so the next screen is assembled rather than invented again.
“AI generated the prototype. Someone has to make it real.”
I read it, keep what works, and rebuild the rest with types, boundaries, and a deploy you can run twice.
“There are designs in Figma nobody has built.”
I build them faithfully, including the states nobody drew — empty, loading, error, and far too much data.
- Next.js
- React
- TypeScript
- Tailwind CSS
- React Query
- Node.js
- Core Web Vitals
Interface first, but the line does not stop at the browser. When a screen needs an endpoint, a schema or a queue behind it, I build that too rather than filing a ticket and waiting for it.
how I build it
TypeScript in strict mode, with types that describe your business rather than restating the shape of a JSON response. Most frontend bugs I get called in to fix were a state nobody should have been able to reach. An order that is both paid and unpaid. A form that is submitting and still editable. Those stop being bugs when the type refuses to let them exist.
Bundle size and data fetching get an owner on day one instead of a cleanup ticket the week before launch. Data that lives on the server is fetched on the server. Interactive components stay small and sit at the edges of the tree. Anything that wants to ship a library to the browser so it can render text has to make its case.
I care what it looks like, and I have opinions I can defend. Spacing on a scale instead of whatever number felt right. A type ramp that still reads at 360 pixels and at 1600. Colour that means something, used sparingly, so that when one thing is highlighted you know why. That is not decoration. It is the difference between a screen someone tolerates and a screen someone trusts.
Accessibility happens while I build, not in an audit afterwards. I read the markup and I tab the page. Focus rings stay visible. Semantics come from using the right element, not from an ARIA attribute patched over a div.
when a project needs more than me
When a project wants brand work or deeper product design alongside the build, I bring in designers I already work with. One arrangement, one schedule, and one person answerable for how it turns out.
what working together looks like
You bring it. I handle it. You get it back better.
you bring
- an idea, a running product, or a prototype somebody generated
- the designs, if they exist
- the people who have the screen open all day
I handle
- frontend architecture and component structure
- UI implementation, down to the states nobody drew
- state management and data fetching
- API integration, and the API itself when it needs one
- responsive behaviour from 360px up
- bundle size, Core Web Vitals, accessibility
you get
- your code, in your repository, from the first commit
- a component library the next engineer can read
- an interface that holds at every width, measured against the standard rather than judged by eye
Have a product that needs building?
Thirty minutes on the idea, the half-built app, or the prototype somebody generated. I will tell you what I would do with it, and whether I am the right person to do it.