How to Hire a Freelance Developer: 2026 Checklist

To hire a good freelance developer: write a one-page brief, check live work, ask how they'd build it, start with a small paid task, and pay per milestone.

I've been on both sides of this. As a freelancer I get hired, and I'm often hired after another developer: to rescue a half-finished app, recover a server nobody has the password for, or fix a site the previous person stopped answering about. Almost every one of those rescues could have been avoided with a few checks before hiring. This checklist is what I'd tell a friend who's about to hire a developer, including me. It works whether you find people on Upwork, Fiverr, LinkedIn or through a referral.

Key takeaways

• A clear brief gets you accurate quotes. One page: who the users are, what they must be able to do, what's out of scope, and your deadline.
• Judge live work, not portfolios of screenshots. Click through real sites and apps the developer built.
• A small paid trial beats any interview. You learn how they communicate, estimate and deliver.
• Pay per milestone for working, visible pieces, not for time or promises.
• You must own the code, domain, hosting and accounts from day one. This is the one rule I'd never bend.

Step 1: Write a one-page brief

Developers quote what they understand. A vague message ("I need an app like Airbnb") gets wildly different prices because each person imagines a different product. A good brief has:

• The goal: what the business needs, in one sentence. "Customers book and pay for cleaning visits online."
• The users: who uses it and what each type of user must be able to do.
• Must-haves vs later: a short list of each. The "later" list matters as much as the first.
• What exists already: designs, an old site, a database, a domain, brand files.
• Budget range and deadline: a range is fine. It helps a good developer propose the right-sized solution instead of guessing.

Not sure what a reasonable budget is? I explain how scope drives price in how much a web app MVP costs.

Step 2: Shortlist on evidence

When proposals arrive, look for these signals:

• They answered your brief. A proposal that mentions your actual users and features beats a copy-pasted list of technologies.
• Live work you can click. Open the sites. Do they load fast on your phone? Do forms work? Are they still online? A developer who builds things that stay up is worth more than a beautiful screenshot.
• Relevant experience. If you need payments, ask for an example of a payment integration. If you need a server set up, ask what they run their own projects on.
• Reviews that mention specifics: "fixed our checkout bug in a day" tells you more than five stars and "great work".
• Clear writing. Most freelance work happens in messages. If the proposal is hard to follow, the project updates will be too.

Step 3: Ask questions that reveal how they work

Skip trivia questions. Ask about your project:

1. "How would you build this, and what would you leave out of version one?" A good developer pushes back on scope and suggests simpler options.
2. "What could go wrong, and what would you need from me?" Look for concrete risks (third-party API limits, content not ready, unclear rules) instead of "nothing, it's easy".
3. "Where will it be hosted, and what will it cost per month?" They should know, and the answer should be in your name.
4. "How will I see progress?" Good answers: a staging link updated as work lands, a shared task list, short weekly updates.
5. "What happens after launch?" Bug-fix period, support plan, documentation, and how you'd hand the project to someone else if needed.

Step 4: Start with a small paid trial

Before committing to a big project, pay for something small and real: fix one bug, build one page, set up the server, or write a technical plan. A few hours of paid work shows you how they estimate, whether they ask good questions, whether they deliver on the day they said, and the quality of what comes back. It's fair to the developer too, because they're paid for their time. If the trial goes badly, you've lost little.

Step 5: Agree on scope, milestones and ownership in writing

A short written agreement prevents most disputes. It should cover:

• Scope: the features included, and a "not included" list.
• Milestones: what's delivered at each step and what each costs. Each milestone should be something you can see and test, like "login and dashboard working on staging".
• Revisions and changes: how many rounds of changes are included, and how new requests are priced.
• Ownership: you own the code and designs once paid. The developer may reuse general knowledge and open-source libraries, but not your private data or business logic.
• Support: how long bugs are fixed for free after launch, and the cost of ongoing help.

On platforms like Upwork or Fiverr, use their milestone or order system, which holds the payment until you approve the delivery.

Step 6: Keep control of your accounts

This is where the painful rescues come from. Create these accounts yourself, in your company's name, with your email, and invite the developer:

• Code: a GitHub or GitLab repository you own. Ask for code to be pushed regularly, not handed over at the end.
• Domain and DNS: registered to you. Never let a developer register your domain in their own account.
• Hosting: the VPS or cloud account billed to you. The developer gets their own SSH key or user, which you can remove later.
• Services: Stripe, email provider, Google Search Console, analytics, app stores. Yours, with the developer added as a user.
• Passwords: shared through a password manager, never in chat messages.

When the project ends, remove the developer's access and rotate any keys they used. It's routine, not an accusation.

Red flags

• No live work, or examples that are all templates with the logo swapped.
• A price far below everyone else with no questions asked about your brief.
• Large up-front payment requested before any work is visible.
• "I'll host it on my server" with no access for you.
• Long silences, then big deliveries you can't test.
• Can't explain in plain words how the app will be secured and backed up. If the project was built with AI tools, ask about the checks in my vibe coding security checklist.

Step 7: Plan the handover from the start

Good projects end with you able to continue without the original developer. Ask for a README that explains how to run, deploy and back up the project, a list of every service and account it depends on, and the environment variables it needs (names and what they're for, not the secret values in the document). If the deploy is automated with something like the GitHub Actions pipeline I use, the next developer can ship on day one.

Frequently asked questions

Where can I find a good freelance developer?

Referrals from people who've hired before are best. Upwork, Fiverr and LinkedIn work well too if you shortlist on live work and specific reviews, then start with a small paid task before the full project.

Should I pay a freelance developer hourly or a fixed price?

Fixed price works best for a well-defined project, because you know the total in advance. Hourly suits ongoing work or unclear problems, such as debugging an unfamiliar codebase. Either way, pay in milestones tied to working results.

How much should I pay up front?

Ideally nothing beyond the first milestone. On platforms, fund one milestone at a time. Off platform, a modest deposit for the first milestone is normal, with the rest paid as each milestone is delivered and tested.

How do I protect my idea when hiring a developer?

Sign a simple agreement covering confidentiality and code ownership, and keep the repository and accounts in your name. In practice, execution matters far more than the idea, and owning your code and accounts is the real protection.

What should I get at the end of a project?

Working software on hosting you own, the full source code in your repository, documentation to run and deploy it, a list of services and accounts, and a short support period for bugs found after launch.

Looking for a developer?

I build web apps and websites with fixed prices, milestones you can test, and everything in your name from day one. Browse my projects, see the MVP package and other web development services, or contact me with your brief. A small paid trial is always welcome.