Dubai · Web Development
Figma to HTML, WordPress, React or Shopify — hand-coded, not exported.
You send a finished design; you get back a front end you can deploy — semantic markup, real responsive behaviour between the widths you drew, keyboard-reachable components, and a repository in your account with a README that runs it from a clean clone.
- No page-builder markup
- Keyboard and contrast checked
- You own the repository
What's included
Six things that happen between the file and the browser.
Tracing the screens is the small half of the job. The rest is everything the design could not say — and that is the half that decides what the site is like to own in year two.
A read of the file, before the quote
We open the Figma file and go through it frame by frame: what is a real component and what is a pasted copy, which widths were drawn, which states exist, whether the fonts are licensed for the web. The gaps come back as a written list, and the price is built on that list rather than on an optimistic reading of the screens.
Markup written by hand
Headings in order, landmarks, real buttons, labelled inputs — structure that means something to a screen reader and to the next developer. Generated markup gives you absolutely positioned containers and a class per element. It looks identical on the day and cannot be changed by anybody afterwards.
The widths between the widths
A design is drawn at two or three sizes. A browser is every size in between, plus a phone held in landscape and a laptop with the sidebar open. How each section behaves at the sizes nobody drew is decided in code, proposed back to you, and reviewed like any other part of the build.
The states nobody drew
Hover, focus, disabled, loading, empty, error — and the table row where somebody typed a forty-word product name. Each of those is a decision, not an omission to be filled in quietly. We list them, propose a treatment in the design's own language, and have it signed off.
Content the editor can move
Where the target is a WordPress or Shopify theme, the design becomes blocks and sections your team can reorder in the editor. Text, images and ordering belong to them; spacing, type scale and colour stay with the system — so the fifth page still looks like the first one.
Checked before it is handed over
Contrast ratios, focus order and keyboard reachability, then real devices and browsers, then page weight against the performance budget agreed at the start. A build that matches the design exactly and stalls on a mid-range Android has not matched the part that mattered.
Who it's for
Three ways people get here, and one condition on all three.
The condition is that the design is settled. If it is still moving, every change costs twice — once in the file and once in the code — and the honest advice is to finish the design first.
A design studio with no front-end team
You sell design and clients keep asking who will build it. Subcontracting the front end lets you quote the whole engagement without hiring for it, and the handover is written for whoever inherits the code — which on this kind of project is usually your client's developer rather than us.
Your last proposal stopped at the Figma file.
A product team the design has run ahead of
The interface was approved weeks ago and engineering is committed to the back end until next quarter. The front end is the piece that can be lifted out and run in parallel, because it depends on the design file rather than on your roadmap.
The design was signed off a month ago and nothing is on staging.
A business holding a design and nothing else
You commissioned a design — from a freelancer, a studio, or an in-house hire who has since moved on — and you have a file, no repository and nobody to build it. What you need is the build. Quoting you for design as well would be selling you something you have already paid for.
You own a Figma file and no code.
How we deliver it
Five stages, and the first can end the conversation.
The file review comes before the price. A design with three widths and full states is a different project from one flat screen, and you should hear which one you have before you commit to anything.
01
File review and target
A frame-by-frame read of the Figma file, written up as what is there and what is not — components versus copies, widths drawn, states drawn, font licences, whether assets can be exported at all. Then the output is agreed: static HTML, a React front end, a WordPress theme or a Shopify theme.
02
Structure before styling
The page skeleton first: heading order, landmarks, component boundaries and what each component is called. Names match the Figma file, so a question about the header component is a question about one thing rather than two things that happen to look alike.
03
Build on a staging URL
Components and their states, at every breakpoint, in weekly increments on a URL you can open whenever you like. There is no reveal at the end — the build is visible from the first week, which is also when disagreements are cheapest.
04
Design QA, side by side
The build and the file open next to each other, at each width, with whoever drew it. Then browsers, real devices, keyboard, contrast and every form path. Deviations from the file are listed with their reason, because a few of them are deliberate and you should know which.
05
Handover
The repository, the README and a walkthrough recorded with whoever will maintain it. Where the target was a theme, editor training goes with it, because a theme nobody on your side can operate is a static site with extra steps.
Stack
Boring technology, chosen so the next developer recognises it.
Nothing here is exotic. That is the point: an unusual stack is a lock-in mechanism dressed up as innovation.
- Front-end
- Next.jsReactTypeScriptTailwind CSSAstro
- CMS & commerce
- WordPressShopifySanityPayloadWooCommerce
Deliverables
What arrives, and what it is like to inherit.
The test is not whether it matches the design on handover day. It is whether somebody who never spoke to us can change it six months later without opening the Figma file to guess.
- The repository in your account with its commit history, not a zip of final files
- A README that runs the project from a clean clone
- Components named to match the components in the Figma file
- Every interactive state built and reviewed — hover, focus, disabled, loading, empty, error
- Design tokens as code: type scale, spacing scale and colour, read from the file rather than eyeballed
- A staging URL from the first week, updated as the build goes
- A WordPress or Shopify theme your editors can operate, where that was the target
- A recorded walkthrough of the codebase with whoever will maintain it
Where the file is missing something the build needs — a width, a state, a long-content case — it goes on a written list before the quote, not into a change request halfway through.
Pricing
What a conversion costs.
Quoted per project
fixed price
A conversion sits outside the published tiers, because it starts from a design that already exists: it is quoted on its own against page count, component count and the output target, and fixed before anything starts. AED 16,000 is the nearest reference point this site has, and it buys the Launch tier — a five-to-eight page site designed and built, which is a different product rather than a version of this one. A large component library, a React front end carrying routing and state, or an Arabic mirror built alongside the English one puts the work in the range of the Growth tier, from AED 48,000. Prices exclude 5% VAT, and payment runs in milestones.
What changes the priceWhat that covers
- A review of the Figma file, and a written list of what it does not contain
- Markup written by hand, not exported or generated
- Every breakpoint drawn, and the widths in between
- Interactive states specified, built and signed off
- Keyboard, contrast and real-device checks before handover
- The repository, a README and a recorded walkthrough
Design studios and agencies
The design is the product here, so the build is read line by line against the file and the studio's reputation is what actually ships. What that work needs is deviation reported rather than absorbed: where a shadow cannot be reproduced faithfully, or a type pairing fails contrast, the decision belongs with the person who drew it.
Software and SaaS products
Interfaces here are components before they are pages, and the same button turns up in forty places. What the sector needs is a build that arrives as a component library with its states, not a set of screens — because the next feature will be assembled from it by an engineer who was never part of this conversation.
Conversion is the narrowest engagement under the wider web development practice and it is the one that starts furthest along, because the hard design decisions are already made. If the design is still moving, or there is no design at all, a custom build is the honest starting point instead.
Questions
Asked before the file changes hands.
They can produce code, and for a throwaway prototype that is often enough. What they produce is rarely maintainable: absolutely positioned containers, a class per element, no heading structure, and a layout that holds at the width the frame was drawn and nowhere else. Typing the CSS was never the expensive part. The structure, the states and the responsive behaviour the file never specified are.
Auto layout, real components rather than pasted copies, and the widths you care about actually drawn. Past that, the more states the file carries — hover, focus, disabled, empty, error — the fewer decisions we end up making on your behalf. None of it is a precondition: we review the file first and send back what is missing, and you choose whether to fill the gaps or have us propose them.
Yes, but the smaller layouts become decisions rather than a conversion. We propose how each section reflows, get that approved as part of the build, and review it at the same time as everything else. It is faster than commissioning a second design and slower than building from a file that already has the widths drawn, which is why the quote separates the two.
It follows what the pages have to do after launch, not what the design looks like. Static HTML suits a landing page or a template pack somebody else will integrate. React or Next.js suits a product interface with state, routing and reusable components. A WordPress theme suits a team that publishes; a Shopify theme suits a catalogue and a checkout. We recommend the plainest option that fits.
Close enough that a side-by-side review at each width is a stage of the project, and any deviation is listed with its reason. Some deviations are deliberate: type renders differently in a browser than on a canvas, a half-pixel rule disappears on some screens, and a colour pairing that fails contrast gets raised rather than shipped. Pixel-perfect describes a screenshot; the build has to work on a device.
Often, and the answer depends on what is inside the file rather than its extension. Sketch and XD files usually carry structure worth reading. A flat PSD, PDF or JPEG is a picture: no spacing values, no components, no states, so the build reconstructs decisions instead of reading them. Rebuilding the artwork as a proper Figma file first is normally cheaper than coding twice from a guess.
Yes, and it is as much a build decision as a translation one. The layout mirrors, icons and progress indicators flip, form alignment changes, and Arabic needs a typeface chosen for it rather than a system fallback. From an English-only file that means proposing the right-to-left treatment section by section for approval — cheaper than a second design pass, and far cheaper than retrofitting it after launch.
Per project, against page count, component count and the output target — not per page and not by the hour. The scope is written down and priced before anything starts, so a state or a breakpoint that was never in the file is a conversation at the quote stage rather than an invoice at the end. Prices exclude 5% VAT, and payment runs in milestones.
Ready to build something that lasts?
Tell us what you need. You will get a scoped response with an indicative price — from an engineer, not a salesperson.