What You Should Check Before Hiring for Figma to HTML Conversion
Most teams that end up with bad outsourced front-end work didn’t choose a bad provider by accident. They chose a provider who looked fine – polished portfolio, reasonable quote, quick first reply – and only discovered the problems once files were delivered and the project was already in motion.
Figma to HTML conversion is a well-defined scope on paper. In practice, it’s where vague agreements produce real fallout: code nobody can maintain, layouts that snap at tablet width, deliverables in the wrong format for the stack you’re building on. The gap between what was expected and what arrived almost always traces back to something that wasn’t confirmed at the start.
This is a working guide to what’s actually worth checking before any file changes hands.
The Gap Between a Good Design and Usable Code
A Figma file is a finished idea. HTML is a working structure that browsers, screen readers, search engines, and other developers all have to interpret. The translation between those two things is where most outsourced front-end projects either hold up or quietly start to unravel.
Some providers treat the conversion as a visual exercise – get the screen to look like the mockup, ship the files, close the ticket. That approach produces code that looks correct in Chrome on a MacBook and misbehaves everywhere else. Overlapping text on a 360px Android screen. A sticky header that doesn’t work on older iOS Safari. A CSS file with seven hundred lines of undocumented overrides.
The quality signals you should be looking for aren’t visible in a screenshot. They’re in the markup.
Five Things That Reveal More Than a Portfolio
Ask for the Code, Not Just the Site
Screenshots and live URLs show you output. They don’t show you structure. Before committing to any provider, ask them to share markup from a comparable past project – a real exported file or a GitHub repo, not a cleaned-up sample assembled for pitches.
Open it. Is the HTML readable? Are elements named in ways that suggest intent – .nav-primary, .card-product, .section-hero – or is there a wall of .div1, .wrapper2, .container-outer-wrap? Is the CSS organised with any discernible logic, or does it look like it was written in the order problems were solved?
A provider who writes clean, readable code will be comfortable showing it. One who doesn’t will find reasons not to.
Find Out How They Handle Breakpoints
Responsive design is where shortcuts appear first, because it’s the dimension clients check last. A provider who delivers a desktop build on a Friday and flags mobile as “mostly done” is a pattern that appears constantly. It’s worth pre-empting.
Ask directly: what breakpoints do they code to, and why those breakpoints? A thoughtful answer will reference common device ranges and explain the logic. A generic answer – “we do mobile, tablet, and desktop” – tells you nothing about whether mobile is handled with care or treated as a checkbox.
Also worth asking: do they test on real devices, or exclusively on browser emulation? Emulators miss real-world rendering behaviour. Position:sticky on iOS Safari. Input zoom on form fields. Font smoothing differences between Android and macOS. These issues surface in actual testing and are invisible in DevTools resize mode.
Understand What “Responsive” Means to Them
This extends beyond breakpoints. For a Figma-to-HTML build, responsive quality depends heavily on what the source file contains. If mobile frames are missing from the Figma, a good developer will flag it before starting. A less careful one will approximate – and you won’t know until you view the result on your phone.
Ask what happens when the Figma file is incomplete. Do they pause and ask, or do they make judgement calls and move on? How they answer this tells you whether you’re working with a team that manages handoff problems professionally or one that takes the path of least resistance.
Test the Communication Before You Test the Work
A development engagement that starts with slow, vague communication will not improve once the work starts. How a team handles the enquiry stage is a reasonable predictor of how they handle the review stage – and the review stage is where delays accumulate.
Pay attention to specificity. A provider who responds to a scoping question with concrete questions of their own – about the number of templates, animation requirements, CMS integration, deliverable format – is demonstrating the kind of attention that makes projects run cleanly. A response that’s warm but non-specific should prompt a follow-up.
Also get clear on the mechanics of the revision process before work starts. How many rounds are included? What counts as a revision versus new scope? What’s the expected turnaround on feedback? These aren’t awkward questions. Any experienced team will have clear answers.
Get Specific About What You’re Actually Receiving
“Figma to HTML” describes a category of work, not a deliverable. The actual output could be flat HTML and CSS files, a WordPress theme, React components, a Shopify section, a Drupal template, or an email build – and those are not interchangeable. If you hand a set of flat HTML files to a developer building a headless CMS integration, the format mismatch creates rework that nobody budgeted for.
Confirm the output format before any work starts. If you know your stack – WordPress, Shopify, a specific JS framework – say so explicitly and check that the provider accounts for it. If you’re not sure yet, ask what formats they typically deliver and what the conversion cost would be if requirements change.
What Buyers Usually Get Wrong
There are a few patterns that come up repeatedly in failed outsourced front-end projects. None of them are particularly surprising in retrospect, but they’re easy to miss in the pre-hire stage.
Treating a polished portfolio as proof of code quality. Design agencies, SaaS companies, and eCommerce brands all curate their portfolios. A front-end developer’s portfolio is the visual outcome of their work, which often reflects a designer’s skill as much as theirs. Code quality is invisible in that format. Ask for something that makes it visible.
Assuming CMS integration is in scope. Converting a Figma file to HTML/CSS and building a functioning WordPress or Shopify site are two different scopes. The first produces templates. The second wires those templates into a live, editable system. Plenty of capable front-end providers do excellent conversion work and stop there. If you need the next step, confirm it’s included.
Not running a small test task. For any project above a single-template scope, a short paid test is one of the more useful tools available to buyers. A real Figma section, a realistic time window, and the actual files they deliver back. The test won’t tell you everything, but it will tell you more than a portfolio and a sales call combined.
Leaving ownership terms unconfirmed. Once code is delivered, who owns it? Most professional providers transfer full ownership to the client, but this should be written, not assumed. A short IP clause in a written agreement takes five minutes and resolves a category of potential dispute entirely.
When Specialist Experience Matters More Than Price
A team that works specifically on design-to-code conversion has already worked through the handoff problems that trip up generalists. They know what incomplete Figma files look like. They’ve seen inconsistent auto-layout applied across frames, missing text styles, components with no mobile variant. They know when to ask and when to make a call.
Generalist developers who handle front-end as part of a broader service offering often produce competent work. But they haven’t necessarily developed the pattern recognition that comes from doing only this, repeatedly, across dozens of different design systems and stacks.
That specialisation shows up most clearly in two places: the quality of the initial questions they ask before starting, and the consistency of the responsive output. A team with narrow focus tends to know what could go wrong, and has built their process around preventing it.
Timezone overlap is a smaller but real factor. When feedback arrives during their business hours and their questions arrive during yours, the review cycle extends. On a project with two or three revision rounds and a tight deadline, the difference between four hours of real-time overlap and none is usually a day or two. Worth factoring in.
A Practical Pre-Hire Checklist
Before signing off on any provider, work through this:
- Have you reviewed actual code from a comparable past project, not just screenshots?
- Have you confirmed they write semantic HTML5 and use a structured CSS methodology?
- Are specific breakpoints and device testing expectations in the written scope?
- Do you know which browsers are covered, and what “tested” means operationally?
- Have you confirmed the output format matches your actual stack?
- Is the revision process defined – rounds, turnaround time, what qualifies as new scope?
- Does the quote itemise what’s included rather than just giving a single number?
- Is IP ownership explicitly covered in writing?
- Have you spoken with a past client, or at minimum read independently verified reviews?
- For anything above a minor single-template job, have you run a paid test task?
If most of these are answered clearly, the engagement is on solid footing. If several remain vague, resolve them before sharing files or making a payment. The problems that appear at the end of projects almost always have their roots at the beginning.
Working With The Site Slinger
At The Site Slinger, Figma to HTML conversion is a core part of what we do – not a sideline attached to a broader agency service. We work in semantic HTML5, use structured CSS methodologies, and build responsive layouts across real breakpoints, tested on real devices.
We deliver in the format your project actually requires – whether that’s flat HTML/CSS, a WordPress theme, a Shopify template, or a component-ready front-end handoff. Before any work starts, we confirm the scope in writing: breakpoints, browser targets, revision rounds, and output format.
If you have a Figma file and want to know what conversion would realistically involve – scope, format, timeline, and how the code gets handed back – send it over. We’ll give you a direct assessment rather than a generic quote.