What to Ask in the First Call With a Freelance Developer for Your Legacy System

Most companies hiring a freelance developer for a legacy system run the same first call: a quick walkthrough of the stack, a question about availability, maybe a rate check. Then they decide based on how confident the person sounded. That approach works fine for a greenfield project where any competent developer can get up to speed. It works badly for legacy work, where the gap between someone who has actually kept old systems alive and someone who only writes new code can cost you months.

The questions to ask a freelance developer about legacy work are different from the questions that work for a normal hire, because the job itself is different. A legacy codebase already has users, data, and failure modes baked into years of decisions nobody fully remembers. The developer you want is one who has spent real time inside that kind of mess and has opinions about how to survive it, not just theories about how software should be built.

Below are twelve questions worth asking in that first call, organized by what they actually test. None of them require you to understand code. What they require is listening for the shape of the answer, not just its confidence.

Questions about the codebase itself

1. What is the oldest system you have worked on, and what was wrong with it?

A developer with real legacy experience answers this in specifics: a PHP 5 application nobody had documented, a Rails app three major versions behind, a database with no foreign keys and three different date formats in the same column. A generalist answers in generalities, calling everything "technical debt" without naming what the debt actually was. Specificity here is the whole signal.

2. How do you usually start, before touching any code?

A good answer involves reading the system before changing it: checking what tests exist, looking at deployment history, finding out which parts of the application actually get traffic and which are dead weight. A weak answer jumps straight to opinions about the stack, or starts talking about a rewrite before they have even seen your repository.

3. What is your process for understanding a part of the system nobody can explain to you?

Every legacy system has code that outlived the people who wrote it. The honest answer describes tracing it: git history, commit messages, old tickets, sometimes just running it in a sandboxed copy and watching what breaks. Anyone who claims they can always figure it out quickly, every time, is either inexperienced or not being honest with you.

Questions about risk and safety

4. What is the worst production incident you have caused, and what did you change afterward?

This is one of the more useful questions to ask a freelance developer, precisely because it is uncomfortable. Someone who has done real production work has broken something in production at some point. The answer worth hearing is not the mistake itself but what changed in their process because of it, a new habit around backups, a different approach to feature flags, a stricter review step before deploys.

5. How do you decide what is safe to change without a full test suite?

Legacy systems rarely come with the test coverage anyone would want. A developer who has actually done this work talks about writing characterization tests around the part they are about to touch, deploying in small reversible steps, and keeping a rollback plan ready before changing anything load bearing. Someone who says testing does not matter much for a project like yours should be a clear warning sign.

6. What would make you say no to a change request?

Good legacy developers push back sometimes. They might refuse to make an unreviewed change directly on production, or flag that a requested fix would paper over a deeper problem that will resurface in three months. If someone says they will do whatever you ask without qualification, that sounds agreeable in a sales call and becomes a liability the first time a bad idea reaches them.

Questions about communication and reporting

7. How will you keep me updated if I cannot read the code myself?

Most non-technical decision makers hiring a freelance developer are not going to review diffs. The right answer describes a reporting rhythm you can actually follow: short written updates, a running list of what changed and why, a plain-language summary before anything risky ships. This is also where you learn whether the developer can translate technical work into terms that let you explain the state of the system to your own management instead of leaving you guessing.

8. What happens when you hit something you did not expect?

Legacy work is full of surprises, a dependency that turns out to be unmaintained, a business rule buried three layers deep that nobody documented. The answer that matters is about disclosure speed. You want someone who flags a surprise the day it happens, with options, rather than someone who quietly absorbs the extra time and tells you at the end.

9. Can you walk me through how you document what you changed?

A developer who leaves no trail is setting up the next person, possibly you, for the exact same confusion that made this project expensive in the first place. Ask what they actually leave behind: updated comments, a changelog, a short note in the repository explaining why a tricky decision was made the way it was.

Questions about scope, commercial terms, and fit

10. How do you estimate work on a system you have not fully seen yet?

Nobody can give you an honest fixed quote for legacy work before looking at the code. A trustworthy answer describes a short paid discovery phase, after which the estimate gets firmer, rather than a confident number pulled out of thin air in a first call. If you want a framework for what the research and discovery phase should cover before full commitment, our guide to hiring a freelance Symfony developer for legacy work covers this in more detail for one common stack, and the same logic applies regardless of the language.

11. What does a typical week look like if you are working alongside my current team, or alone?

This question tells you whether the developer has actually worked inside someone else's process before, attending standups, using your ticketing system, respecting an existing code review culture, or whether they expect you to adapt to them. Neither answer is automatically wrong, but you want to know which one you are getting before the contract starts.

12. What would make this a bad fit for you?

This is the question most hiring conversations skip, and it is often the most revealing one. An experienced freelance developer has turned down projects before, usually because the timeline was unrealistic, the scope kept changing without a budget conversation, or the client wanted a rewrite the data did not support. Someone willing to name their own limits in a first call is more likely to be honest with you later, when honesty is harder to hear.

Using the answers, not just the questions

None of these twelve questions has a single correct response you can check against a script. What you are listening for across all of them is a consistent texture: specific examples instead of general claims, comfort admitting past mistakes, and a communication style that assumes you cannot read the code and plans around that rather than ignoring it.

If several answers in a row feel vague, generic, or oddly rehearsed, that is worth weighing as heavily as a technical red flag would be. The developers who have actually kept legacy systems running tend to have stories, not slogans, and the first call is usually enough time to tell the difference.

If you would rather have someone else run this conversation and the technical screening that follows it, Wolf-Tech helps non-technical teams evaluate freelance developers and agencies for legacy and custom software work, including the scoping and code quality review that should happen before any contract is signed. Reach out at hello@wolf-tech.io if you want a second opinion before you commit.