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.
THE PROBLEM
Alongside my own client work I spent four years leading React front ends at Peymynt and a year building Nuxt.js applications at Sumashtech. 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. The design was the expensive part; it is worth building accurately. 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, and that is the condition worth optimising for.
Div elements standing in for buttons, focus states removed for looking untidy, forms with no labels. Accessibility is a legal requirement in a growing number of markets and it is 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. Keeping components small and honest is what keeps a codebase moving.
SCOPE
PROCESS
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.
BENEFITS
You get back what your designer drew, including the states and details that make it feel finished, rather than something in the general vicinity of it.
Optimised for mid-range phones on ordinary networks, which is 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.
RELEVANT WORK
Most of my frontend application work sits behind client login screens and NDAs, so it is not something I can publish as a case study. The history is on the record instead:
A year building and maintaining Nuxt.js applications, focused on responsive, high-performance interfaces.
Four years as Senior Frontend Developer leading React work on a financial product, alongside cross-functional product teams.
Four years of WordPress and frontend delivery across a wide range of client projects.
The publicly linkable builds are in the portfolio, and the full history is on the homepage.
TESTIMONIALS
Every completed Upwork contract to date, each rated 5.0. The work behind them was WordPress — my frontend references are available on request — but the way a project runs is the same whichever platform it is on.
“Ashekur was a total lifesaver on this project. From the very first message, his communication was prompt, clear, and friendly. He dove straight into the work, quickly grasped my requirements, and delivered a rock-solid solution ahead of schedule—without a single hitch.”
“He is very punctual on timelines and has a complete inside out knowledge of WordPress theme development.”
“Ashekur Rahman delivers the work timely and perfectly. His knowledge in wordpress is very vast and he can do anything in wordpress and web developement.”
FAQ
What people ask before bringing in a frontend developer, answered up front rather than in the first call.
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 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