The build does not match the design
Approximated spacing, an invented type scale, hover states nobody implemented. I work from the Figma file directly and raise responsive problems before building, not after.
Interfaces built to the design, fast on real devices, accessible by default and readable by whoever maintains them next — from a single Figma file to a full component library.
Interfaces built to the design, fast on real devices, accessible by default and readable by whoever maintains them next — from a single Figma file to a full component library.
That is the background I bring to product teams now: I am comfortable owning the frontend layer of an application, not just styling pages. Most of what makes a front end good is unglamorous — the state that does not get tangled, the component that is genuinely reusable, the layout that holds at 320 pixels, the interaction that still works with a keyboard.
Approximated spacing, an invented type scale, hover states nobody implemented. I work from the Figma file directly and raise responsive problems before building, not after.
Oversized bundles, render-blocking scripts, images shipped at full resolution, layout that shifts while loading. Real users are on mid-range phones and imperfect networks.
Div elements standing in for buttons, focus states removed for looking untidy, forms with no labels. Far cheaper to build in than to retrofit.
A component that has grown a dozen boolean props and three special cases is one everybody works around instead of using.
I go through the design file before writing anything, and flag the places that will not survive a narrow viewport or a long string of real content. Catching these in review costs minutes; catching them in QA costs days.
What is a component, what is a page, what is shared, and where state actually belongs. Deciding this deliberately is the difference between a codebase that scales and one that calcifies.
Semantic HTML first, then styling, then behaviour — so the thing works before it is decorated. Mobile-first, tested at real breakpoints on real devices rather than in a browser resize.
Keyboard navigation, focus order, screen reader labels and colour contrast, alongside bundle size, code splitting and Core Web Vitals. A dedicated stage with its own checklist.
Readable code, a clear commit history, and documentation of anything non-obvious. The measure of a good handover is that the next developer does not need to ask me anything.
You get back what your designer drew, including the states and details that make it feel finished, optimised for mid-range phones on ordinary networks — where your users actually are and where Core Web Vitals are measured. Conventional patterns, small components and honest naming, no clever abstraction that only makes sense to the person who wrote it.
React and Next.js, Vue and Nuxt.js, and plain JavaScript where a framework would be overhead. Four years of that was leading React work at Peymynt and a year building Nuxt.js applications at Sumashtech, so both are production experience rather than side-project familiarity.
Yes — that is a large part of what I did across my years on agency and product teams. I follow the conventions already in the codebase rather than importing my own preferences, and I would rather ask than guess about anything architectural.
No, and I would rather be clear about that than stretch. I work at the frontend layer and integrate with whatever API your backend team provides. For WordPress and Webflow projects I handle the full build, because the backend there is the platform.
Yes, and it is a significant share of my work. I build to the file accurately, including hover and focus states, empty states and error states — the parts that are easy to skip and obvious when they are missing.
If the project has a testing setup, I work within it. If you want one established, that is worth scoping explicitly rather than assuming — it changes the estimate and it is better discussed than discovered.
Both. I take fixed-scope projects and ongoing part-time arrangements with product teams. I am freelance full-time, so availability is a scheduling question rather than a moonlighting one.
Available for new projects
NEXT STEP
Based in Dhaka, Bangladesh, working with clients worldwide. Describe the project and where it is stuck — every serious enquiry gets a reply within one working day.
ALSO WORTH READING