How do you vet a freelance developer so they don't disengage right after handoff?

Most agency owners vet freelance developers on skill. Skill is the easy part to check. The developer who ghosts you two weeks after handoff almost never ghosts because the code was bad. They ghost because nothing in the engagement made staying engaged more valuable than moving to the next gig. If you want a developer who sticks around for support, bug fixes, and the inevitable client change request, you have to build the incentive to stick around into how you hire, not just what you hire for.

Start with a small paid test, not a portfolio review

A portfolio tells you what a developer built once, with unlimited time and no client breathing down their neck. It tells you nothing about how they behave under a real deadline with real ambiguity.

Before handing anyone a client project, run a small paid test task, something that takes two or three days and touches the actual stack you use. Watch how they handle the inevitable unclear requirement. Do they ask a clarifying question or guess and ship? Do they flag a risk before it becomes a bug, or wait for you to find it? That behavior, not the finished code, is what predicts whether they show up after handoff.

Ask what happens after they say the project is done

This is the single question most agency owners skip. Ask directly: after you deliver, how do you handle a bug that shows up in week three? A developer who has thought about this will describe a support window, a rate for post-launch fixes, or a retainer structure. A developer who has never thought about it will say something vague like "just message me," which sounds reassuring and means nothing. You are not looking for a perfect answer. You are looking for evidence they have a system for the part of the work that happens after the invoice clears.

Structure payment so disengagement costs them something

A single lump sum on delivery gives a developer every reason to disappear the moment the check clears. Split payment across milestones, and hold back a meaningful piece, ten to twenty percent, tied specifically to a support period after launch, thirty days is enough to catch most real-world bugs. This is not about distrust. It is about making the incentive structure match the outcome you actually want, which is a developer who is still answering messages after the client has started using the thing in production.

Some agency owners feel awkward proposing this. Don't.

A developer with a real practice, who plans to work with agencies again, will not blink at a holdback tied to a defined support window. The ones who push back hard on any structure besides full payment upfront are telling you something useful about what happens next.

Get a reference that covers the ending, not just the work

When you check references, most people ask "was the work good." Ask instead: "did they stay reachable after delivery, and for how long." A past client who says the developer vanished after the final invoice is giving you the exact failure mode you are trying to avoid, and they will usually tell you plainly if you ask the right question instead of the generic one.

Put the support window in writing before the first line of code

Do this first, before you evaluate anyone's portfolio or run a single test task. Define, in the contract, what "done" means, how long post-handoff support lasts, and what it costs beyond that window. A developer who disengages after handoff is often doing exactly what the contract implied was fine. Fix the contract, and you fix most of the disappearing act before it starts.