How to choose a freelance developer for your agency: 8 questions before handing over a project

For a web agency, a design studio or a communications agency there always comes a moment when development becomes a bottleneck: too many projects at once, a client asking for a feature nobody in-house knows how to build, a peak of work that does not justify a hire. That is when you think of a freelance developer.

The choice is delicate because you are putting your relationship with a client in their hands. Here are eight questions to ask before handing over a project, and what to listen for in the answers.

1. How long have you been working, and on what kinds of projects?

Experience is not everything, but a long and varied track record suggests the person has already seen most of the problems that come up. Ask for examples of work similar to yours and, when possible, the sites they have built.

What to listen for: concrete answers about real projects, not just lists of technologies.

2. Have you already worked with other agencies?

Working with an agency is different from working with a direct client. You need respect for other people's processes, communication with a project manager, scheduled deadlines and deliveries. Someone who has already collaborated with agencies knows what is expected.

What to listen for: familiarity with agency tools and workflows, such as Figma, Jira, Slack and shared repositories.

3. How do you handle white-label and confidentiality?

If the client is yours, the developer must never contact them directly. Ask how they handle communication, whether they sign a non-disclosure agreement (NDA) and how they treat materials and access.

What to listen for: clarity on these points without your having to insist.

4. How do you estimate time and costs?

A serious estimate comes with a clear scope, timing by phase and an indication of what is not included. Be wary of figures given verbally with nothing in writing.

What to listen for: questions about the brief before the numbers are given, and a written estimate within a reasonable time. The most common formulas are per project, with a fixed quote, or by the day with an agreed allowance.

5. How do you work with a design that is already done?

If your agency designs in Figma, the developer must be able to read the file, spot ambiguities and protect fidelity to the design. I talk about it in From Figma to WordPress.

What to listen for: questions about components, mobile version and element states, before starting.

6. How do you deliver the code and who owns it?

The code should live in shared repositories, to your standards, with access in your name or the client's. A good developer delivers clean, documented code that others can pick up.

What to listen for: no hidden dependency on them. If they were unavailable tomorrow, another developer must be able to carry on.

7. What happens after delivery?

A site needs support, fixes and updates. Ask whether a support period is included, how emergencies are handled and what the response times are.

What to listen for: a precise answer, without a vague "we'll see". For WordPress sites, remember there is also regular maintenance.

8. What can't you do?

This is the most revealing question. A serious professional has limits and states them: "I don't do this one, but I can tell you who can", or "for this I suggest another route". Whoever answers "I can do everything" deserves a little more doubt.

What to listen for: honesty and the ability to say no when needed.

Signs worth trusting

• They ask questions before giving a price.
• They put estimates, timing and scope in writing.
• They show online previews during the work, not only at the end.
• They respect your process and your tools.
• They explain problems simply, without hiding behind jargon.

Signs to be wary of

• Promises of timing and costs before having seen the project.
• No concrete example of work done.
• Access, code or domains in their name and not yours.
• Unclear or slow communication already in the preliminary phase.
• Refusal to sign a non-disclosure agreement.

How to start without risk

The safest way to get to know each other is to start with a small, well-defined project. After the first delivery you will have a much clearer idea of reliability, quality and way of working than any interview can give you.

How to organise the collaboration day to day

A good collaboration rests on simple habits.

• One contact per side. A project manager at the agency and the developer: requests go through them.
• The usual tools. The developer uses your channels and your task-management systems, without asking you to change them.
• Updates at a fixed rhythm. A short mid-week summary avoids surprises.
• Accessible test environments. An online address where you can see the work in progress, to show the client.
• A rule for changes. What is included, what is extra, who authorises.

Introducing the developer to the client, or not

In many cases the agency prefers the client not to know who is developing: that is white-label. In others the developer takes part in a technical meeting. Both choices are legitimate, as long as they are clear from the start. What matters is that roles are defined and that communication with the client always stays with whoever holds the relationship.

What a good brief should contain

The clearer the brief, the more precise the estimate. Include, even briefly:

1. who the client is and what business they are in;
2. the project goal: what the site or app must achieve;
3. available materials: design, copy, images, existing access;
4. required features and connections with other systems;
5. deadlines and constraints (launches, campaigns, events);
6. mandatory technologies, if there are any;
7. indicative budget, if you have one, to guide the choices.

You do not need a perfect document: a ten-line brief is better than none, and the gaps are filled with a short phone call.

Why entrust it to me

I am a freelance web developer in Rome, active since 1999, with more than 300 projects delivered. I have worked with about 30 agencies as an external developer, often white-label: my role is to be the programmer your team is missing.

In practice: you send me the brief, even a short one, and you receive an estimate with timing and costs within 24-48 hours. I adapt to your tools and processes, deliver in stages with test environments you can show to the client, use shared repositories and never contact your client directly. I sign NDAs and work per project or by the day.

If you have a project coming up or a peak of work to handle, write to me: a chat of about 20 minutes, no strings attached. You will find everything in Developer for agencies and on the Working together page.