How to hire a freelance designer who can deliver
A founder’s guide to hiring a freelance designer: check real contributions, constraints, working fit, and delivery before committing to the work.
One of the design engagements I’m glad we took began with a project we declined.
The founders were building an image-generation platform in a market moving fast enough that features were being scrapped while still in development. Our working arrangement left us effectively a day behind product decisions, which were already changing again.
More overlapping hours wouldn’t have been enough. I would have needed to be alongside the founders, involved in product decisions as they happened, understanding the thinking behind each change. We explained the mismatch during discovery and recommended an in-house team for that product.
They later came back with a separate idea: MyDrip, a personalized shopping app. It didn’t even have a name when we started. We had substantial freedom to define the UX and UI, and more than two months to think through the work.
The second project wasn’t more certain. It gave us room to respond to the uncertainty. I think of this as a decision’s shelf life. Does a decision stay useful long enough for the designer to understand it and act on it?
That’s the distinction I’d want a founder hiring their first freelancer to understand. You’re choosing someone whose judgment, capabilities, and way of working fit the situation you’re actually in.
I offer freelance design and frontend development myself. I have a commercial interest in this subject. But some of the best outcomes of a hiring conversation are deciding to use a template, commission a smaller piece of work, or hire someone other than me.
First, decide what needs to change
An investor meeting is approaching. The website looks unfinished, the app is inconsistent, and you want someone to clean everything up. That’s a recognizable situation, but “make us investor-ready” doesn’t yet tell a designer what to do.
Does the website fail to explain the product? Does the demo bury its most useful feature? Are the core screens difficult to use, or do they simply look like several engineers built them independently? Those problems can overlap, but they don’t call for the same work.
If the meeting is next week, I’d rather agree on the few things that must work for that audience than promise a complete redesign on an implausible schedule. Looking credible matters. It isn’t a guarantee of funding.
The same distinction applies to a bootstrapped founder asking for a modern UI and better conversion. “It looks dated” is an aesthetic judgment. “People abandon onboarding” is a behavior to investigate. Check the measurement, look at where people struggle, and find out whether the interface is responsible before commissioning its replacement. Pricing, traffic quality, or a broken integration won’t necessarily improve with new typography.
This is also why I find the GOV.UK guidance on understanding user needs useful beyond government services: investigate the problem and test assumptions before committing to a solution. Its measurement guidance combines research with contextualized metrics. A new product without meaningful usage data needs a way to test assumptions, not an invented conversion baseline.
A template or an AI-assisted build may be enough for the immediate need. The question is whether someone on your team can judge the result, handle the real interaction states, and maintain it. Hire when you need judgment, execution, capacity, or ownership you don’t already have—not because using a tool somehow disqualifies the work.
Ask what the portfolio actually proves
A beautiful portfolio is a good reason to start a conversation. It isn’t enough evidence to make a hire.
Self-directed work can be excellent. It can also have unlimited time, ideal content, no existing codebase, and no customer asking awkward questions. That doesn’t make it dishonest. It means you haven’t yet seen how the designer behaves when those conveniences disappear.
I’d look for evidence of constraints. Pick a piece and ask the designer to explain a limitation that changed it. What did they personally own? What did they decide not to do? What actually shipped?
The explanation matters as much as the image. A designer who can connect a decision to a user need, a deadline, or a technical limitation gives you something you can evaluate. A screen that resembles your industry gives you familiarity. Those aren’t the same thing.
Don’t demand confidential files as proof. A walkthrough of permitted process work, a public implementation, or a relevant client reference may help corroborate the account. Team projects are perfectly legitimate portfolio material; claiming the whole team’s contribution as your own is not.
I learned to check attribution the expensive way. I once hired someone through a freelance platform who presented other people’s work as their own. An image search led me to a Dribbble profile that didn’t match the profile they had supplied. I reported the freelancer to Dribbble and Contra, and they were subsequently removed from both platforms. I recovered half the fee, not all of it.
Google’s image search is a preliminary check, not a verdict on authorship. Collaborators can legitimately display the same project, and a search can miss copied work. Investigate the contribution, and don’t upload confidential material without permission.
Hire for the gap in your team
If you already have engineers who can implement UI well, a designer who provides a clear handoff may be exactly what you need. Agree on responsive behavior, loading and error states, reusable patterns, assets, and how implementation questions will be resolved. Polished desktop screens alone leave a lot for the engineer to guess.
If your small team is mostly backend specialists, someone who can design and implement the frontend may fill a more useful gap. You’ll see this combination described as a design engineer. The title still needs unpacking. Does the person prototype, build production interfaces, maintain components, or mostly work on marketing websites?
Ask who owns each part of your work rather than assuming the title answers it.
My own coding experience expanded substantially with agentic coding tools. Before that, it was mostly jQuery for specific changes to WordPress and Webflow sites. Learning to build made me more systematic about design: I now look for patterns a family of screens can share before creating another one-off solution.
For a role that includes implementation, the ability to generate code is not enough evidence that someone can take responsibility for a production interface. Ask about testing, accessibility, integrations, and what happens after launch.
Whether you hire a freelancer or an agency, on a subscription or a retainer, find out who will actually do the work, how much capacity is available, and which responsibilities they accept.
How you work
Ask candidates how they would work with your pace of decisions. If priorities expire between conversations, sending more detailed briefs may not solve the problem. You may need someone involved in product decisions as they happen.
Tell candidates how you plan, how frequently you introduce features, when standups happen, and who makes the final call. Explain how much involvement you want. Some founders want to think alongside the designer; others want to set direction and review periodically. Agree on this before committing; a mismatch can make both people miserable.
During those conversations, I’d be wary of effortless agreement. Someone who endorses every request before understanding it may be selling reassurance rather than offering judgment.
I’d rather hear uncertainty with a useful next step: what needs investigating, how much time or money to spend, and what decision the result will inform. A designer can commit to the work without guaranteeing that your conversion rate will rise or your investor will say yes. “I don’t know yet” is useful when it comes with a way to find out.
Agree on scope and price together
I’ve taken on projects worth a few hundred US dollars that needed only a few hours of work, and projects worth more than $50,000 that required months. That range tells you very little until you know what each engagement included. For me, the useful pricing conversation starts with defining the scope.
Most of my work falls into app UI/UX or website design. For app work, I look at the number and complexity of screens, whether we need a design system or an interactive prototype, and whether I’m starting from scratch or extending an existing system. A screen count gives us somewhere to begin. It still needs to account for loading, empty and error states, responsive behavior, and how the screens connect.
Website scope can vary even more. A page might use existing assets and straightforward layouts, or need original illustrations, custom icons, motion graphics, and code. Two proposals for a five-page website can describe very different amounts of work. List those responsibilities before asking whether the price is reasonable.
What the rate benchmarks tell you
If you need an initial reference point, YunoJuno’s 2026 rates report lists average UK day rates of £385 for its Design discipline and £452 for UX. Its US hourly averages are $63 and $75 respectively. The report draws on platform data from 2024 and 2025, so these are historical benchmarks published in 2026, not a live price list.
Upwork’s UX designer cost guide lists $25–$39 an hour, based on certain historical contracts worldwide. These sources cover different markets and populations. Neither establishes what every freelancer should charge, and an hourly rate alone doesn’t tell you the total cost.
Use a relevant benchmark to orient your budget, then ask suitable designers to quote the same brief. Ask what effort and assumptions sit behind the fee. A higher hourly rate can still produce a lower total if the work takes fewer hours; a low quote can become expensive if it leaves implementation or essential states to someone else.
Choose how to pay for the scope
A fixed project fee is useful when you can agree on deliverables, feedback rounds, and acceptance. Hourly or daily billing gives you room to investigate or change direction, but agree on a spending limit and when the designer must ask before continuing. Upwork’s comparison of hourly and fixed-price projects makes the same distinction between paying for time and paying for defined deliverables.
If the work is too uncertain to quote responsibly, commission a bounded discovery phase first. Use what you learn to price the next stage. For ongoing work, a retainer needs to specify the capacity or deliverables it buys, how priorities are set, and what happens to unused time. A monthly payment doesn’t define those things by itself.
The pace of decisions matters here too. If priorities change as quickly as they did on the image-generation project, a fixed fee for an entire product needs frequent scope renegotiation. Paying for a limited period of work may fit better, provided you agree on what to review before buying more time.
Leave room to negotiate
Whatever pricing model you choose, be prepared to negotiate. I like to leave some room in the fee for that conversation. I may also lower my fee when I think there’s a good chance of further work with the same client. That’s a judgment about the relationship, not a discount every client is entitled to because they mention future projects.
As a founder, share your budget and ask what can fit within it. You might postpone the interactive prototype, use existing illustrations, or commission the most important flow first. If the designer agrees to a lower fee, write down whether the scope changed too. If it didn’t, make the discount explicit so it doesn’t quietly become the expected price for every future engagement.
Compare proposals on scope and responsibility before comparing rates. A quote covering design, implementation, and post-launch work is a different offer from one covering design files. Neither the more expensive nor the cheaper quote tells you, on its own, who is more competent.
Before paying, I’d want the agreement to make these things understandable:
- What will be delivered, and what is excluded?
- What does the founder need to provide, and when?
- How will feedback and scope changes be handled?
- What counts as accepted work, and how do the deposit, milestone payments, and final payment relate to delivery?
- What currency is the quote in, and are taxes, platform fees, licenses, and other expenses included?
- Who owns the files and code, and what support remains after delivery?
“Maintenance included” is not a substitute for defining duration and scope. Fixes, new features, and ongoing evolution should not quietly become the same commitment.
Start small
When there’s still meaningful uncertainty about the fit, start with a paid, bounded piece of real work. One flow or page, a feedback round, and a handoff can reveal more about working together than another portfolio presentation.
Agree on the deliverable and what you’re evaluating. Did the designer understand the problem? Did they ask useful questions, explain choices, respond to feedback, and deliver what was agreed? You’re not buying another portfolio image.
Price this trial as a small engagement in its own right. Ask the designer to quote for the briefing, design work, feedback round, and handoff, or agree on their hourly or daily rate with a cap. Don’t calculate it as an arbitrary percentage of a larger project that neither of you has agreed to yet.
For example, a trial could cover one onboarding flow using your existing components, one review, and annotated files for the engineer. Specify which states are included and whether a clickable prototype is needed. That gives the designer something they can estimate, and gives you something concrete to accept. Pay for the agreed work even if you decide not to continue together; agree upfront whether its fee will count toward a later phase.
An investor demo is a different brief. Define which journey it must show and whether you’re buying a clickable prototype or working code. Calling it a demo doesn’t make those responsibilities disappear.
This doesn’t need to become a compulsory audition. Strong references and directly relevant work may already answer enough questions. A small first milestone can provide the same learning without adding a separate hiring stage. Don’t ask candidates for unpaid speculative work and call it due diligence.
Ask how they handle a slipping deadline
Ask about a project where the deadline became unrealistic. When did the designer tell the client, and what did they propose? If you speak to a reference, ask whether they had enough notice to make a decision.
A useful update explains what changed, what it affects, and the available choices. Perhaps you can preserve the date by reducing scope. Perhaps the full scope needs a revised date. Look for evidence that the designer raised the problem promptly and agreed on a new plan with the client.
The responsibility runs both ways. Missing access, late feedback, and changing priorities can delay the work too. The designer should flag blockers promptly; the founder should understand how their responses affect delivery.
Feedback needs the same care. “People can’t find the next step” gives the designer a problem to investigate. “Make it pop” gives them a guessing game. Involve the designer in conversations with people who use the product; they will have questions worth asking.
That doesn’t make design a vote. You can disagree with the designer and your customers about a particular solution. You can make the final business decision. Explain the constraint and engage with the tradeoff, rather than asking for more versions until the designer reproduces an unstated preference.
Before committing to a longer engagement, ask one more question: what will my team be able to do without you afterward? Useful documentation, editable assets, maintainable code, and an agreed handover make the relationship less fragile. A freelancer can be valuable without making themselves indispensable.
Work with me
I work on product UI, UX, website design, and React frontend development. For design-and-development engagements, I can build and evolve a product-specific system of reusable components, design tokens, and guidelines that fits your brand. I call this design system as a service. It’s not something every product needs.
My frontend work can include API integration, testing, accessibility, deployment, and maintenance, with the scope and support terms agreed for the engagement. The underlying backend needs to be provided separately.
I only implement my own designs. Rough sketches and wireframes are welcome, but if you have finished designs and need implementation alone—or need a non-React frontend—I’m not the right person for that work.
If that sounds like the gap in your team, you can send an inquiry here.
