What do you need from us to start?

The Figma file with view or edit access, the fonts and any licences attached to them, the icon set, and a note of anything already decided about the stack. If the site is being deployed by us we also need hosting or repository access. The single thing that most affects both price and timeline is the state of that Figma file, so we look at it before quoting rather than after.

What do you build in?

Whatever the project needs and your team can maintain. Static HTML and CSS for marketing pages, Tailwind where that is already your convention, React components where the design is going into an existing application. If you have no stack yet we will recommend one and say why, weighted toward what you can keep running rather than what is newest.

Our Figma file is messy. Does that matter?

It matters to the price, and we would rather say so before starting than discover it in week two. A file with real components, named styles and auto layout can be read almost directly. A file of loose frames with hand-nudged spacing has to be interpreted first — every value has to be inferred and every repeated element identified by eye. Where that is the case, the proposal carries an explicit uplift written into it, and you can decide whether to tidy the file yourself instead.

Will it be pixel-perfect?

It will be compared element by element against the design and every difference documented, which is not the same promise. Some differences are deliberate — a fixed height that breaks with real text, a font size that fails contrast at that colour, a layout that cannot survive a long product name. Those are flagged with the reason rather than silently reproduced. What we will not do is call something close enough because it is only a few pixels out.

Do you handle deployment?

Yes, where you want it. Vercel or Netlify for static and framework builds, or into your own pipeline where one exists. Ownership stays with you throughout — the repository, the hosting account and every login are yours, and if we set anything up it is set up in your name rather than ours.

We are an agency and this is for our client. How does that work?

Communication runs through you, files are delivered to you, and we do not contact your client unless you ask us to. Where it is useful we will join a call on your side. Progress is reported in a form you can forward without editing, which tends to be the practical thing agencies actually want.

UI/UX & Design

Design-to-code handoff

Your Figma file built as responsive, accessible front-end code, then compared against the design element by element until the differences are ones you chose.

From: $400–$4,000
Typical time: 1–4 weeks
Usually bought by: Design studios

What this actually solves

There is a specific and very common gap between a design existing and a design being live, and four kinds of buyer are standing in it.

A design studio has excellent designers and no front-end developer, so beautiful files pile up waiting for someone. A product company has a developer who is fully committed to the application, which means the marketing pages never reach the top of the queue. A founder was handed a Figma file by whoever they hired first and now needs it to become a website. And increasingly, someone generated a site with an AI tool, it works, and it does not resemble the design at all — the spacing is arbitrary, the type scale has drifted, and you can see every one of those differences even if you cannot yet put words to them.

That last case is worth naming because it is the fastest growing one. Generated code is often structurally fine and visually approximate, and approximate is exactly the thing a design studio is unable to sign off. The work here is closing that gap deliberately, with a comparison rather than an impression.

What we do, and in what order

Assess the Figma file before quoting. Are there components, named styles, auto layout, a consistent spacing scale? Or is it frames with values nudged by hand? This single question changes the estimate substantially, so it is answered first and the answer is written into the proposal. Half a day.
Extract the tokens and identify the repeats. Colours, type scale, spacing values, radii and shadows pulled out into variables, and a pass through the design marking what appears more than once and therefore becomes a component rather than a copy. One day.
Build it, section by section. Semantic markup, real components where the design repeats, and no fixed heights on anything that contains text you will one day make longer. Three days to two weeks.
Compare side by side, element by element. The design and the browser next to each other, checking spacing, text size, line height, colour, corner radius, border weight and alignment. Differences are listed and ranked — the ones the eye catches immediately first, the two-pixel ones last — and worked through in that order rather than fixed at random. One to two days.
Make it responsive, and check it properly. Three widths at minimum — 390px, 768px and 1440px — and then on an actual phone, because the mobile view in DevTools is a narrow desktop browser and not a phone. Text rendering, tap targets and scroll behaviour all differ. One to three days.
Accessibility and browsers. Keyboard operation through every interactive element, focus states that are visibly present, contrast measured against the 4.5-to-1 threshold for body text. Then Chrome, Safari and Firefox, because Safari will do something different and it is better to find out now. One to two days.
Performance and deploy. Images sized and encoded for what they actually display at, fonts loaded so they do not arrive late and shift the layout, then deployment and handover of the repository and accounts. One to two days.

Tools are Figma Dev Mode for values, VS Code for the build, Chrome DevTools for the comparison, Tailwind where it fits the stack, and Vercel or Netlify for deployment.

What moves the price

The range is $400–$4,000 and three things set it.

The condition of the Figma file. This is the largest single factor and it is the one most quotes ignore. A disorganised file roughly doubles the work, because every value has to be measured rather than read and every repeated element has to be recognised by eye. It is stated as an explicit uplift in the proposal before anything starts.

Scale and type of output. A single landing page sits at the bottom of the range. A site of fifteen pages sits in the middle. A set of React components going into an existing application, with props, states and documentation, sits at the top.

How much is interactive. Static sections are quick. Filtering, sorting, multi-step forms with validation, and anything that changes state on the page are each their own piece of work, and they are the parts that make a page slow rather than the markup.

What usually goes wrong

Sign-off happens on the machine it was built on. Everything is correct on the developer's screen, in their browser, at their window size. You open it in Safari and the font renders with different weight, or your laptop is narrower and two elements collide, or the sticky header eats the first heading on a phone. Three widths, at least two browsers, and a real device before every delivery — not once at the end.

A quote given before the design file is opened. A clean file and a chaotic one look identical in a project brief and are not the same job at all. Quoting on the brief and discovering the file afterwards is the reliable way to deliver this work late, over budget, and with a conversation about scope that nobody enjoys.

The match is eyeballed instead of compared. Close enough is where the 6px paddings, the 1.4 line heights and the slightly wrong grey live. Individually invisible, collectively the reason a design studio says it does not look right and cannot say why. The comparison is run as an explicit pass with a written list of differences, because a design that has been checked from memory has not been checked.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

What do you need from us to start?: The Figma file with view or edit access, the fonts and any licences attached to them, the icon set, and a note of anything already decided about the stack. If the site is being deployed by us we also need hosting or repository access. The single thing that most affects both price and timeline is the state of that Figma file, so we look at it before quoting rather than after.
What do you build in?: Whatever the project needs and your team can maintain. Static HTML and CSS for marketing pages, Tailwind where that is already your convention, React components where the design is going into an existing application. If you have no stack yet we will recommend one and say why, weighted toward what you can keep running rather than what is newest.
Our Figma file is messy. Does that matter?: It matters to the price, and we would rather say so before starting than discover it in week two. A file with real components, named styles and auto layout can be read almost directly. A file of loose frames with hand-nudged spacing has to be interpreted first — every value has to be inferred and every repeated element identified by eye. Where that is the case, the proposal carries an explicit uplift written into it, and you can decide whether to tidy the file yourself instead.
Will it be pixel-perfect?: It will be compared element by element against the design and every difference documented, which is not the same promise. Some differences are deliberate — a fixed height that breaks with real text, a font size that fails contrast at that colour, a layout that cannot survive a long product name. Those are flagged with the reason rather than silently reproduced. What we will not do is call something close enough because it is only a few pixels out.
Do you handle deployment?: Yes, where you want it. Vercel or Netlify for static and framework builds, or into your own pipeline where one exists. Ownership stays with you throughout — the repository, the hosting account and every login are yours, and if we set anything up it is set up in your name rather than ours.
We are an agency and this is for our client. How does that work?: Communication runs through you, files are delivered to you, and we do not contact your client unless you ask us to. Where it is useful we will join a call on your side. Progress is reported in a form you can forward without editing, which tends to be the practical thing agencies actually want.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Design-to-code handoff All UI/UX & Design services