How to Hire a Developer: The Complete Guide for Businesses and Founders

Here's how to hire a developer without the usual regrets: define the job before you look for people, choose the right hiring model, judge candidates on real work, test the fit with a small paid project, and sign a contract that leaves you owning the code and the accounts. Most hiring mistakes happen before the first call, not after it.

A quick disclosure. I'm a freelance developer based in Denmark, not a recruiter or a marketplace, so I don't earn anything by placing other people. I do have an interest in you hiring someone like me, so read with that in mind. I'll be just as direct about when you shouldn't.

The short answer: nine steps from first idea to working relationship

This is the whole process on one page. The rest of the guide walks through each step and points to the detailed guides where there's more to say.

On a smaller project, steps 3 to 6 can take a couple of weeks. Steps 1, 2 and 8 are the ones people skip, and they're the most expensive to fix later. If you only need 10-50 hours of work, you can compress several steps, which I cover in the guide to hiring a developer for a small project.

Before you search: define the job and choose a model

Step 1: Write a one-page brief

The most useful preparation costs you a few hours and nothing else. Before you contact anyone, write a short brief. It doesn't need to be technical. It needs to answer five questions:

1. What problem are you solving, and for whom? Describe the users and the workflow that should improve.
2. What does version one need to do? The smallest version people can actually use, not the dream version.
3. What already exists? Systems, data and integrations the new software has to work with, such as Stripe, HubSpot or your accounting tool.
4. What are your constraints? A budget range, a deadline, and the reason behind the deadline.
5. Who makes decisions on your side, and how much time can they give the project?

Without a brief, you get quotes you can't compare. One developer prices a lean first version (an MVP, or minimum viable product), another prices a full product with every feature you mentioned in passing, and the gap between the numbers says nothing about who is cheaper. My project brief template gives you a starting point.

If you're not technical, describe the business and the workflows, not the technology. Choosing frameworks and hosting is the developer's job to propose and your job to have explained in plain language. I wrote a full guide on hiring a developer as a non-technical founder.

Step 2: Choose the hiring model that fits the job

Once the job is clear, you can decide who should do it. That choice shapes where you search, what you pay and which risks you need to manage. My rule of thumb:

• Hire a freelancer when the scope is clear: an MVP, a customer portal, an integration, or ongoing development on a product that already runs. You talk directly to the person writing the code, but you depend on one person.
• Hire an agency when design, copy, user research and development all need to happen in the same weeks. You get a team and one contract, and you pay for the agency's overhead.
• Hire an employee when software is your business and needs daily work for years. Expect recruiting to take months.
• Look for a technical co-founder when you're building a startup and need a partner who shares the risk. You pay in equity rather than invoices.
• Use an outsourcing firm or offshore team when you need volume at a lower rate and have someone technical in-house to manage the work.

For the full trade-offs on cost, risk and quality, see my comparison of freelancer vs agency. If you're weighing a partner against a supplier, read how to find a technical co-founder, and when a freelancer is the better call. Mixed setups often work well too: a freelancer builds version one, then helps your first in-house developer take over.

When not to hire a freelancer like me

I make a living from being hired, so this might be the most useful part of the guide. Choose something else:

• When off-the-shelf software covers most of what you need. Booking tools, online stores and CRMs already exist for a fraction of the cost. Build custom only when the standard tool would force you to change a workflow that gives you an edge.
• When you need a full team at once, for example a new brand, new copy and a new platform in the same quarter.
• When development is a full-time job for years. You'd be paying for flexibility you never use.
• When nobody on your side has time to answer questions and make decisions. That breaks every model.
• When the job calls for a specialist in a stack I don't work in. I work mainly with Laravel, PHP and modern JavaScript such as React and Next.js.

Finding and vetting candidates

Step 3: Look where good developers actually are

Start with referrals. A developer who has already done good work for someone you trust has passed the hardest test there is: delivering for a real client. Ask your network, your accountant and other companies that have had something similar built.

If referrals don't get you far enough, there are four other routes:

• LinkedIn and professional communities, where you can see what people have worked on and who you know in common.
• Freelance platforms such as Upwork, Toptal or Malt, where you'll get plenty of names quickly but have to filter hard. They work best for well-defined tasks.
• Brokers and IT consultancies, which find the candidate and handle the contract. Their fee is usually built into the rate, so ask what share of it goes to the middleman.
• A developer's own website and writing, which shows you how they think and explain things before you've spoken.

Location matters less than overlap. A developer in Central Europe, for example, overlaps almost the entire working day with the UK and the rest of the EU, and usually has a few hours of overlap with the US East Coast. If you're on the US West Coast, plan for mostly written, asynchronous collaboration.

I've written separate guides on where to find developers, the best freelance developer platforms compared and what IT consultant brokers actually charge for. Aim for three to five strong names, not thirty.

Step 4: Judge real work, not résumés

A résumé tells you what someone was part of. Past projects tell you what they can do. Ask to see two or three projects similar to yours, then dig in:

• What exactly was your role, and what did others do?
• What was the hardest part, and how did you solve it?
• Is it still running, and who maintains it today?
• What would you do differently if you started over?

You don't need to read code to use the answers. Notice whether the developer can explain technical decisions in plain language, and whether they talk about the client's business or only about the tech. That's the language you'll be working in for months. My guide on how to evaluate a developer when you're not technical goes deeper, and I've put together the questions to ask a developer before hiring.

Watch for warning signs as well. A developer who agrees to everything without asking questions, sends a fixed price after a ten-minute call, or won't put the code in your repository is telling you something. The full list is in red flags when hiring a developer.

Step 5: Call past clients

Reference checks are the step most people skip, and the cheapest one to do. Ask for two clients from projects like yours, ideally one where the work has ended. Fifteen minutes on the phone with each is enough.

Don't just ask whether they were happy. Ask what happened when something went wrong, because something always does. Were deadlines met, and if not, did they hear about it early? How did changes mid-project go? Would they hire this developer again for a similar job? These reference check questions for developers explain what each answer tells you.

Test the fit and agree on price

Step 6: Start with a small paid engagement

An interview shows you how someone presents. Real work shows you how they operate. Before you commit to a large build, start with something small, scoped and paid.

For larger projects, I start with a paid discovery phase at a fixed price. It clarifies the scope and the biggest technical risks, and you end up with a plan and an estimate you can budget against. Make sure the result is yours to keep, even if you hire someone else to build it. It's the best way I know to test a working relationship, because you see how a developer asks questions, prioritizes and writes before you've signed up for something big.

I don't recommend unpaid test tasks. Experienced developers often turn them down, so you filter out the people you most want, and a task that fits into one evening says little about a project that runs for months. The guide to paid trial projects with developers covers the options and their trade-offs.

Step 7: Compare quotes and agree on pricing

There are three common ways to price development work:

• Fixed price for a well-defined project. You know the cost upfront, but changes along the way are agreed and priced separately.
• Time and materials, billed hourly or by day rate, for ongoing work. Ask for a monthly cap so the budget can't run away.
• A monthly retainer for maintenance, so security updates and small fixes happen without a new quote every time.

When you compare quotes, read what's included and what isn't. Are testing, documentation, hosting setup and project management part of it? What happens after launch? Which assumptions is the price based on? A quote far below the others has usually left something out. That can be fine, as long as you know what it is.

If you need a lower price, negotiate scope rather than rate. Move features out of version one and keep them for later. You get a smaller bill without pushing the developer to cut corners on testing and quality. Here's my take on how to negotiate with a developer, and my pricing page shows how I price my work, so you know what to expect before you get in touch.

Contract, code and accounts

Step 8 is what protects you when the relationship ends, whether it ends well or badly. This paperwork matters more than the price.

What the contract must cover

A signed quote isn't a contract. Make sure your agreement covers at least:

• IP assignment. In most European countries, code an employee writes on the job typically belongs to the employer, but code written by a freelancer doesn't. The US works similarly: code from an independent contractor generally doesn't count as work made for hire, so the copyright stays with the developer unless it's assigned to you in writing. Either way, your contract needs an explicit assignment.
• Payment and milestones: what you pay for, when, and what must be done before each payment.
• Change requests: how new wishes are estimated and approved before anyone works on them.
• Bug fixing after delivery: for how long and on what terms.
• Termination and handover: what you receive, and how, if either side stops.
• Confidentiality, if you share sensitive business information. It can sit in the main contract or in a separate NDA.
• A data processing agreement (DPA) if the developer will handle personal data of people in the EU, for example by accessing your production database. Under GDPR, the controller-processor relationship must be governed by a contract.

Hiring across borders adds two points. When a freelancer in one EU country invoices a business in another, VAT is usually paid by the customer through the reverse-charge procedure. And if a contractor works only for you, full-time and under your direction, some countries may treat them as an employee for tax purposes. Check both with your accountant.

None of this is legal advice. If a lot is at stake, have a lawyer review the contract. My freelance developer contract checklist lists 14 points, and I've written about when an NDA with a developer makes sense.

Accounts that must be in your name

The contract gives you the rights on paper. The accounts give you control in practice. Create these in your company's name and invite the developer as a user:

• The code repository, for example on GitHub or GitLab.
• Hosting and servers.
• Domains and DNS.
• Third-party services such as payments, transactional email and analytics.

My clients own the code from day one, and you should ask the same of anyone you hire. I go deeper on who owns the code when a freelancer writes it and on how to avoid vendor lock-in with your developer.

Onboarding and keeping the collaboration healthy

Step 9 starts the day after you sign. The first few weeks set the tone for everything that follows.

The first two weeks

Give the developer what they need to start without waiting: access, test data, one named contact person and a prioritized list of what comes first. Agree on what "done" means. Is a task done when the code is written, or only when it's tested and live? My onboarding checklist for freelance developers has ten things to prepare for day one.

A steady rhythm

When a project drifts, the code is rarely the only problem. More often, it's unclear priorities and decisions piling up. Three habits prevent most of it:

• One shared task list that both you and the developer work from.
• A short written update every week: what's done, what's next, and what's waiting on you. Written updates also work across time zones.
• A demo of working software every week or two, so you can react early.

For meetings, messages and expectations, see the guide on how to work with a developer.

When things go off track

Deadlines that keep slipping, replies that get shorter and demos that never happen are signs to take seriously early. Raise it straight away and ask concretely what it would take to get back on track. Many of the common reasons software projects fail can be fixed if they're caught in time.

If that doesn't help, step 8 is what saves you. When the code and accounts are yours, a new developer can take over. I explain how to do it with the least damage in how to switch developers mid-project.

Next steps: a checklist before you sign

Use this as a final check before you sign with any developer.

If you can tick every box, you've covered the things that most often go wrong. To see the kind of work I take on, from websites and web apps to SaaS products and ongoing maintenance, have a look at my services.

Frequently asked questions

How long does it take to hire a developer?+

With a freelancer, it usually takes a couple of weeks from first contact to kickoff, depending on when they have space in their calendar. A discovery phase can often start sooner than the main build. Hiring an employee typically takes several months of recruiting, and then the candidate's notice period at their current job comes on top.

Should I hire a developer locally, in Europe or offshore?+

It depends on how much coordination you can handle. Offshore developers can have lower rates, but time zones, language and contracts under another country's law make the work harder to manage. If you're not technical, a developer whose working hours overlap with yours and who you can easily call is often cheaper in total, even at a higher rate.

How do I check code quality if I can't read code?+

Pay for an independent code review. Another experienced developer can review the code at a milestone in a few hours and tell you whether there are obvious problems with structure, security or testing. It costs little compared with the project and gives you the right questions to ask before problems get expensive.

Can I hire a developer for just a few hours a month?+

Yes, many freelancers offer small monthly retainers for maintenance and minor changes. It suits software that already runs and needs to stay up to date. Expect a monthly minimum, because even small tasks require getting back into the code. Also agree on how quickly you can expect a response when something is urgent.

When should I switch from a freelancer to an in-house developer?+

When there's a full-time workload every week and you can see years of development ahead. Until then, a freelancer is usually cheaper and more flexible. Plan the switch: ask the freelancer for ongoing documentation, and use them to assess candidates and get your new hire up to speed on the codebase.