Hiring a Freelance Full-Stack Developer: What to Actually Look For

I’ve been hired as a freelance senior developer enough times, and referred enough other developers to clients, to have opinions about what actually predicts a good outcome versus what just looks good in a first call. Most of the common advice (“check their portfolio,” “ask for references”) is directionally right and almost useless in practice, because it doesn’t tell you what to actually look for once you’re looking.

Portfolio polish is a weak signal

A polished portfolio site tells you someone can build a polished portfolio site. It doesn’t tell you how they behave when a production database migration needs to run without downtime, or how they communicate when a feature is going to take longer than estimated. I’d rather see a case study — even an informal one — that describes an actual problem, the constraints, the decision made, and the outcome, than a gallery of finished screenshots. Ask for the story behind one project, not a list of projects.

Ask how they’d approach a problem you actually have

Not a whiteboard algorithm question — an honest, specific version of a real problem in your codebase or product. “We need to let external suppliers submit data through a portal without giving them full accounts — how would you think about that?” A strong senior developer will ask clarifying questions before proposing an approach (what’s the trust boundary, how many suppliers, does this need to scale to thousands or is it a handful for now) and will name tradeoffs explicitly, not just present one confident answer as if there’s no decision being made. A weaker signal is someone who jumps straight to a specific tech stack without asking about constraints first.

Communication cadence, tested before you hire

The single biggest predictor of a freelance engagement going well or badly, in my experience on both sides, isn’t technical skill — it’s whether status updates happen proactively or have to be extracted. Ask directly: “how do you handle it when something’s going to take longer than you estimated?” The answer you want is some version of “I flag it as soon as I know, with the reason and the new estimate” — not “I push to hit the original deadline” (a red flag for corner-cutting) and not a vague non-answer.

Check how they talk about past clients and past code

Someone who can describe what went wrong on a past project, and what they’d do differently, is showing you they reflect on their own work critically — a much stronger signal than someone who describes every past engagement as flawless. Similarly, watch how they talk about a codebase they inherited versus one they built from scratch. “This existing code was a mess and I rewrote it” said about every single past project is a signal worth probing — sometimes it’s true, and sometimes it means the person defaults to rewriting instead of understanding.

Scope the first engagement small, on purpose

Rather than committing to a large multi-month project on a first hire, a smaller, well-scoped first engagement — two to four weeks, a real but bounded piece of work — tells you far more about how someone actually works than any interview can. Does the estimate hold? Does communication stay proactive under real deadline pressure, not just in the sales conversation? Do they ask good questions when requirements are ambiguous, or guess and ship the wrong thing? You learn this by working together, not by asking about it.

Technical range matters more than a single technology match

A developer who’s shipped production systems across a genuinely full stack — frontend, backend, cloud infrastructure, third-party integrations, AI/LLM features — brings judgment about how decisions in one layer affect another, which is exactly the judgment a growing product needs most. Someone deep in exactly one framework can be excellent within that framework and still make architecture decisions that don’t account for how the frontend, backend, and infra layers interact. For most early-to-mid-stage products, breadth with real production depth beats narrow specialization, at least until the product’s scale genuinely demands specialist expertise in one layer.

What I’d actually check, in order

1. One detailed case study, not a portfolio gallery — a real problem, real constraints, real outcome
2. Their answer to a real (not hypothetical/algorithmic) problem from your own product
3. How they describe handling a slipped estimate
4. How self-critically they discuss past work
5. A small, real, paid first engagement before a larger commitment

None of this requires reading code you can’t evaluate yourself. It requires a conversation designed to surface judgment and communication — which, past a baseline level of technical competence, is what actually determines whether a freelance engagement goes well.