How to Hire a Freelance Developer

Most failed development projects were not badly coded. They were badly specified, hired on the wrong signal, and handed over so incompletely that the next developer had to start again. The technical part is rarely where the money goes missing.

That is good news for a non-technical buyer, because it means the decisions that matter most are ones you are qualified to make. You do not need to assess someone’s JavaScript to hire well. You need to be able to describe the problem precisely, recognise relevant evidence, ask questions that are hard to bluff, and insist on a handover that leaves you holding the keys. This guide walks through all four.

Decide what you are actually building

Start with the outcome, not the technology. “I need an app” is not a brief; “customers need to book and pay for a slot on their phone, and I need to see tomorrow’s bookings in one list” is. The second version can be quoted, tested and argued about. The first cannot.

Before you talk to anyone, write down four things:

• The job to be doneWhat a user should be able to accomplish that they cannot today. One sentence per capability, in the user’s language rather than a technical one.
• The must-havesThe handful of things without which the build is pointless. If your list has more than six, it is a wish list, not a specification.
• What already existsCurrent site, hosting, domain, payment provider, CRM, spreadsheets. Every integration is work, and undeclared integrations are where estimates break.
• Who maintains itSoftware is not a purchase, it is a commitment. Decide now whether you will retain the developer, hire someone else, or manage it yourself.

A useful discipline: describe the first version as the smallest thing that would be genuinely useful. Everything else goes on a second list. Developers quote the first list; the second list is what you fund once the first one is earning.

What kind of developer you need

“Developer” covers a dozen distinct trades that are not interchangeable. Hiring the wrong one is the most common and most expensive category error in this process.

• Front-endWhat the user sees and touches: layout, interaction, responsiveness, accessibility. Hire for a redesign, a marketing site or a new interface on an existing system. See front-end development freelancers.
• Back-endData, logic, APIs, authentication, payments. Hire when the value is in what happens after the button is pressed. See back-end development freelancers.
• Full-stackBoth, to a working standard. The right choice for most small builds, because coordination between two specialists costs more than it saves at small scale.
• CMS and platformWordPress, Shopify, Webflow and similar. If your requirement is met by an existing platform, hiring a custom developer to rebuild it is money burned. See WordPress development and Shopify development.
• MobileNative iOS or Android, or cross-platform. A genuinely different discipline from web, with its own store-review and release constraints. See mobile app development.
• Maintenance and fixesDebugging, updates, performance, security. Often the highest-value hire of all, and the one buyers postpone longest. See website maintenance.

If you genuinely cannot tell which you need, that itself is a small, cheap, well-defined job: pay an experienced developer for a short scoping conversation before you commission anything.

Choosing the technology before the person

You do not need to choose the language. You do need to make one decision: platform or custom. It has more effect on your total cost than any other choice in this guide.

A platform build — WordPress, Shopify, Webflow, a no-code tool — means most of the software already exists and you are paying for configuration, design and the parts that are specific to you. It is faster, cheaper, and easier to hand to the next person, because thousands of developers know it. The limit is that you live inside the platform’s assumptions.

A custom build means the software is written for you. It fits exactly, and it costs several times as much to create and to maintain, because only the person who wrote it knows it until they document it. Custom is the right answer when the thing you do is the product; it is the wrong answer for a brochure site or a standard shop.

Two practical rules. First, if a mainstream platform does eighty per cent of what you need, start there and pay for the missing twenty. Second, whatever is chosen, ask why — a developer who cannot explain the choice in terms of your requirements is choosing what they like, not what you need. If you are weighing up a full site build, our website cost guide sets out the bands.

Writing a brief a developer can quote

A good technical brief is short and specific. It does not tell the developer how to build; it tells them what must be true when they have finished.

• The problem, in one paragraph. What is happening now, and why it is not acceptable.
• The user stories. “As a customer, I can … so that …”. Five to fifteen of these is a real specification.
• The integrations. Name every external system by name, including the ones you consider trivial.
• What you are supplying. Copy, images, designs, logins, test data. Undeclared gaps become billable hours.
• Constraints. Deadline, budget range, hosting you must stay on, compliance you must meet.
• The definition of done. Deployed where, tested how, documented to what level, handed over with what.

Include a budget range. Buyers withhold it hoping for a lower quote; in practice it just produces proposals aimed at the wrong scale, and you lose a round of correspondence discovering that. Our guide to writing a project brief that gets great proposals has a fuller template, and hourly vs fixed price explains which pricing model your brief is asking for.

Building a shortlist

Aim for three to five candidates. Fewer and you have no comparison; more and you will not do the assessment properly on any of them.

There are two directions to search from. Start from the work if your job is well defined and you want to buy something specific — browse fixed-price listings under website development, software development or web applications, or by marketplace at web design, WordPress developers, mobile app development or Shopify experts.

Start from the person if the work needs discussion. Browse developers by discipline or by tool — React, WordPress, PHP, Python or Webflow — or post the brief and let proposals come to you. On Zinn Hub, posting a project is free, and you can direct it at a specific area such as website development, back-end development or mobile app development.

Filter hard on relevance and lightly on everything else. A developer who has shipped three things like yours beats one with twice the experience in a different domain, almost every time.

How to read a developer portfolio

You cannot audit someone’s code, and you do not need to. A portfolio still tells you a great deal if you know what to look at.

• Open the live links. A screenshot proves nothing. Load the site on your phone, use it, break it. Anything broken today was signed off broken.
• Look for problems like yours. Not the same industry — the same shape. A booking flow is a booking flow whether it sells haircuts or helicopters.
• Check what they did. On team projects, ask which parts were theirs. “I worked on it” can mean a great deal or very little.
• Test the basics yourself. Does the page load quickly? Does it work on a phone? Are forms usable with a keyboard? These are craft signals a non-technical buyer can read perfectly well.
• Read the reviews as a body of evidence. One glowing review is noise. A pattern across many, especially about communication and deadlines, is signal. On Zinn Hub reviews require a confirmed purchase.
• Ask what went wrong. The strongest answer to “tell me about a project that went badly” is a specific, unflattering, well-analysed story. There is no such thing as a developer with only smooth projects.

For a systematic version of this, work through our 12-step freelancer vetting checklist.

Questions to ask before you hire

The aim is not to catch anyone out. It is to hear how someone thinks when the answer is not rehearsed.

• Explain a past build“Walk me through one of these projects and the trade-offs you made.” A good developer will name something they chose not to do and why. Jargon with no trade-offs is a warning sign.
• What worries you hereAsk what the riskiest part of your brief is. Anyone who says “nothing, it is straightforward” has not read it properly.
• What is missing“What would you need from me that I have not provided?” Strong candidates answer this immediately and in detail.
• How will I see progressA staging link, a weekly update, a shared board. Any answer is fine; no answer is not.
• What happens after launchBug window, support terms, documentation. Agree this before you start, not when something breaks.
• Who owns the codeAsk directly. The answer should be you, on delivery, in writing, including everything needed to run it.

Test before you commit

The cheapest insurance available to a buyer is a small paid job before a large one. Not an unpaid trial, which good freelancers decline and which tells you nothing about how someone behaves when money is involved — a real, small, paid task.

A good test task is representative, self-contained and finishable in a sitting: fix a specific bug, make one page responsive, add a form and wire it up, improve a slow page. What you are really assessing is not the code. It is whether they asked a clarifying question before starting, whether they delivered what was asked rather than what they preferred, whether they explained what they did, and whether the timescale they gave was the timescale you got.

On Zinn Hub the natural format is a Micro Zinn — a fixed-price task at $5, $10, $15 or $20. Browse bug fixes and small code tasks or website bug fixes and tweaks, or start from a price with $20 Micro Zinns. Our guide on testing a freelancer before you commit covers how to structure and judge the test.

What it costs and how to pay

Development pricing varies more than any other freelance category, because the work varies more. What follows are typical market bands for the whole job, not Zinn Hub prices, and every freelancer sets their own.

• Small task

  Under $200

  A bug fix, a plugin conflict, a form, a speed pass, a small feature on an existing build. Best bought as a fixed-price task.

• Standard build

  $500–$2,000

  A platform-based site or shop: theme configuration, several page templates, forms, basic integrations, launch.

• Advanced

  $2,000–$8,000

  Custom functionality, accounts and logins, payments, third-party integrations, or a bespoke design implemented from scratch.

• Application

  $8,000+

  A real software product: multi-role systems, dashboards, mobile apps, anything with meaningful back-end logic and ongoing engineering.

Costs vary by scope, complexity and experience. Use the bands to sanity-check a quote rather than as a tariff — if a number sits two bands away from where your brief belongs, that gap is the conversation worth having.

On Zinn Hub, every Zinn carries a price set by its Zinner, buyers pay no platform fee, and all prices are in USD with an approximate equivalent shown in your own currency. An order is paid and protected as a single whole amount; there is no staged or milestone release, so a phased build is placed as separate orders or agreed as separate priced phases in your project brief. Choose a Platform Protected Zinner and your payment is held by Zinn Hub until the order completes; any refund is credited to your Zinn Wallet in full, in USD. Zinners who connect their own PayPal or Stripe account are paid directly at checkout instead.

Ownership, access and handover

This is the section buyers skip and later regret. Agree all of it in writing before work starts, because after delivery you have no leverage left.

• Accounts in your name. Domain, hosting, and any third-party service should be registered to you, with the developer added as a user. Never the reverse.
• Code ownership on delivery. State plainly that on final payment the work is yours to use, modify and take elsewhere. Ask about any third-party components with their own licences.
• Repository access. Even if you never open it, you must be able to give it to the next developer.
• Credentials, all of them. Admin logins, API keys, database access, deployment access — transferred and confirmed working before the final payment.
• Documentation. A short written note on how to deploy, where things live, and what to do if it breaks. One page is enough; nothing is not.
• A bug window. A defined period after launch in which genuine defects are fixed at no extra cost. Thirty days is a common, reasonable ask.

Copyright and licensing terms vary by country and by contract, so treat this as general guidance rather than legal advice and get professional advice on anything commercially significant.

Mistakes that sink development projects

• Hiring before the brief exists. Every hour spent specifying saves several in build and rework. Nothing else on this list matters as much.
• Choosing on price alone. The lowest quote is often the one that understood the least, and the difference surfaces as change requests.
• Adding scope quietly. Small requests during a build are how fixed prices become disputes. Batch them, price them, decide on them.
• No staging environment. Reviewing work only when it is live is how a broken site gets discovered by customers instead of by you.
• Skipping the mobile check. Most of your visitors are on a phone. Approve nothing you have not opened on one.
• Leaving handover until the end. The moment to agree access and ownership is before the first commit, not during the last invoice.
• No maintenance plan. Software rots. Budget for updates, backups and security from day one, or pay for a rescue later.
• Ignoring the warning signs. Vague answers, missed small deadlines and pressure to pay outside the platform are all covered in our guide to common freelancer scams.

If you are still deciding whether a freelancer is the right route at all, freelancer vs agency compares the two honestly for a small business build.