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

For an agency, handing development to a freelancer means putting part of a client relationship in their hands. The risk is less technical than about reliability: meeting deadlines, quality that is not visible straight away, communication, confidentiality, what happens once the project is finished. I have worked as an external developer for agencies for many years; these are the questions I would ask, and what I would listen for in the answers.

1. What projects have you done, and which resemble mine?

Not a list of technologies, but concrete projects, with the role played in each. Ask for those closest to yours in type (corporate site, e-commerce, application) and complexity. A portfolio of brochure sites says little about an integration with a management system.

What to listen for: precise accounts of problems solved, including the ones that went wrong.

2. Have you worked with other agencies?

Working for an agency is different from working for a direct client: there is a project manager, processes and tools you do not choose, interim deliveries, reviews from the creative team. Someone used to it slots in without friction.

What to listen for: familiarity with Figma, ticketing, shared repositories, code reviews.

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

The client is yours, and must stay yours. Ask how they handle communication, whether they sign a non-disclosure agreement, how they treat access and materials, whether they mention projects in their portfolio and with whose permission.

What to listen for: clear rules, proposed by them, without you having to push. I go deeper in White-label web development.

4. How do you estimate time and cost?

A serious estimate comes after questions about the brief, with stated assumptions and exclusions, split into phases. The most common models are per project, at a fixed price, or by days with an agreed budget of hours.

What to listen for: questions before numbers. A flat figure within an hour on a complex project is a warning sign. How to prepare the brief is in How to write a brief for a developer.

5. How do you work from a Figma design?

If your creative team designs in Figma, the developer must read the file, flag ambiguities and undesigned cases before estimating, and protect fidelity at every width.

What to listen for: questions about components, variants, states, mobile version, tokens. I cover this in From Figma to WordPress.

6. Where does the code live and who owns it?

The code goes in a repository under the agency's or client's control, with readable commits, documentation and a staging environment. No hidden dependencies: if the developer were unavailable tomorrow, someone else must be able to carry on.

What to listen for: an unprompted proposal of repository, previews and documentation.

7. What happens after delivery?

Post-launch bugs, small changes, updates, maintenance. Ask what is included, with what response times and on what terms the collaboration continues.

What to listen for: a defined support period and a clear proposal for afterwards.

8. What can't you do?

It is the most useful question. Nobody can do everything, and anyone who claims to will sooner or later improvise on your client's project.

What to listen for: limits stated naturally, and a pointer to when it makes sense to involve someone else.

Signs of reliability and warning signs

Good signs: precise questions about the brief, an offer of continuous previews of the work, clear contracts and confidentiality, code in a shared repository from day one.

Warning signs: instant estimates without questions, vague answers about code ownership, access kept in their own name, no visibility of the work until delivery.

How to start

A contained pilot project, with clear scope, deadline and acceptance criteria. It shows method, quality and communication better than any interview, and reduces risk for both sides.

How to run the collaboration day to day

Once the developer is chosen, a few rules prevent most friction:

• a single channel for requests, with one contact on each side;
• written tickets or tasks, not verbal requests nobody can find later;
• one branch per topic and an online preview for every delivery, available to the project manager;
• a short weekly check-in on progress, blockers and priorities;
• acceptance criteria for each delivery, so "done" means the same thing to everyone;
• out-of-scope changes estimated before being done, not discovered on the invoice.

On the relationship with the end client, the rule is that the agency decides: the developer can stay invisible or be introduced as part of the technical team. What matters is that the choice is clear and kept for the whole project.

My take

Working with agencies is the core of my business, and I have learned that what matters to an agency is not just that the code works: it is having no surprises. That is why I always work with shared repositories, one branch per topic, online previews the project manager can review before every release, and confidentiality rules agreed at the start. I do not mention agencies' clients without their permission, and the relationship with the end client stays yours.

And I am happy to answer question 8: I say upfront what I do not do, and when a project is better suited to someone else.

For me, the first project is always a mutual test as well.

Why work with me

I have been programming since 1999, delivered more than 300 projects and worked as an external developer with about 30 agencies, including white-label, from Rome and remotely. I fit into your processes, work from Figma and deliver documented code in your repositories.

If you are looking for a developer for your agency, get in touch: a call of about 20 minutes to see whether we can work together. How I collaborate with agencies is explained in Collaborations.