9 Developer Reference Check Questions to Ask Past Clients

The best developer reference check questions ask what actually happened during the project, not whether the client was happy. Almost every reference says yes to that one. The questions that tell you something are about the final bill versus the quote, how bad news was delivered, how scope changes were handled and who controls the code today.

I'm a freelance developer, so read this with that in mind. These are the questions I'd ask if I were the one hiring for a project that mattered.

The short answer: 9 questions and what they reveal

Each question is designed to pull out a story. A reference who has to explain what happened can't get away with "it was fine". The reference check belongs near the end of the process, when you're down to one or two candidates. If you're earlier than that, my step-by-step guide to hiring a developer covers the whole route from first brief to signed contract.

Before you call: how to get honest answers

Most references want to be helpful, but nobody enjoys criticizing someone to a stranger. Your job is to make honesty easy. That takes a bit of preparation and the right format.

It matters even more when you're hiring across borders. A company in Germany or the Netherlands working with a contractor in Denmark, or a UK startup hiring someone in Poland, often signs without ever meeting the developer in person. The reference call is the closest you'll get to asking around locally.

If you've already interviewed the developer, bring your notes. Some of the best follow-up questions come from comparing what the reference says with what the developer told you. If you haven't had that conversation yet, start with the questions to ask a developer before hiring.

Questions about the project and expectations

1. What did the developer build for you, and how big was the project?

First, find out whether this reference is relevant at all. Ask what was built, how long the engagement lasted and whether it was a fixed-scope project or ongoing work. You don't need an exact budget, but a rough sense of scale helps: a few weeks or a full year?

A good answer is specific, something like "they built our booking system and the integration with our accounting software over about four months". An answer like "he helped with some stuff on our website" is a warning sign on its own, because you can't tell what you're comparing against. If you need a SaaS built and the reference had a simple WordPress site done, you'll learn something about the working relationship but nothing about whether this developer can handle your project.

2. How did the final result and price compare to the original agreement?

Very few software projects land exactly on the original quote, and that alone isn't a problem. The problem is when the client gets surprised. So don't just ask whether the budget held. Ask when the client found out it wouldn't.

A good answer sounds roughly like this: "We went over budget, but we knew early, and it was because we added two features ourselves." A bad answer involves invoices nobody saw coming, or a delivery that quietly shrank without anyone saying so.

Follow up with "when did you first hear it would take longer?" That tells you whether the developer raises uncomfortable news right away or waits until it can't be hidden. If the reference is in a different EU country from the developer, also ask whether invoices were correct and on time. Cross-border B2B services inside the EU are usually invoiced without VAT under the reverse charge procedure, and a contractor who gets it wrong creates work for your accountant.

3. Who did you actually talk to, and how quickly did they reply?

Ask what a normal week looked like. Were there regular check-ins, short status updates, or only contact when the client chased? How long did emails usually sit before getting an answer?

Listen for who the client was actually dealing with. With a freelancer, the answer should be the developer. If the reference mentions a colleague, a subcontractor or someone who took over after kickoff, dig in. Subcontracting isn't wrong, but you should know about it before you sign so you know who is writing your code.

If the client was in another time zone, ask how that worked day to day. Did meetings happen at reasonable hours for both sides, and did questions get answered within the client's working day?

Questions about accountability when things go wrong

The next three questions matter most. Satisfaction tells you how a project ended. Accountability tells you how your project will go on the day something breaks, and in most projects that day comes.

4. Tell me about a time something went wrong. What did the developer do?

Phrase it as a prompt, not a yes/no question. Ask "did anything go wrong?" and most people say no. Ask for a story and you'll get one.

Good answers tend to look alike: the developer spotted the problem or flagged it immediately, explained what happened without jargon, proposed a fix and owned their own mistakes without an argument. Bad answers look alike too: the hosting company, the previous developer or the client was to blame, and the developer was hard to reach while it was happening.

If the reference says nothing went wrong, try a different angle: "Was there anything that took longer than expected?" A project that ran for several months without a single bump is rare, so the reference may be remembering it more kindly than it deserves.

5. What happened when you changed your mind mid-project?

Nearly every client changes requirements once they see the first screens. That's normal. What you want to know is how the developer handled it.

There are two traps. One is the developer who says yes to everything without mentioning cost or time, then delivers late. The other is the developer who rejects every change with "that's not in the contract". The good answer sits in between: the developer explained what the change meant for the price and the timeline, and the client made the call.

Follow up with "did you get changes confirmed in writing?" If yes, the developer keeps their agreements tidy. If no, expect arguments about invoices later.

6. Did the developer ever push back or talk you out of something?

This question separates advisors from order-takers. An experienced developer pushes back when a feature costs more than it's worth, when an off-the-shelf tool would do the job, or when an idea will cause problems a year from now.

A good answer might be "they talked us out of building our own billing system and set up Stripe instead". An answer like "no, they just built what we asked for" can sound like praise, but it means you'll be making every technical decision yourself. That's rarely what you're paying for.

Questions about ownership and life after launch

7. Did you have access to the code, servers and accounts throughout?

This question is easy to forget, and it's the one that costs the most when the answer is wrong. Ask whether the code lived in the client's own repository or the developer's. Ask who owned the hosting account, the domain and the accounts for payments and transactional email.

A good answer is that the client had access to everything from day one, even if the developer handled the daily work. A warning sign is a reference who doesn't know where the code lives, or who mentions that everything is in the developer's name "to keep things simple". With me, the client owns the code from day one, and I recommend keeping hosting, the domain and other accounts in the client's own name. Expect that from any developer, me included.

If the software handles personal data about EU residents, also ask whether a data processing agreement was in place. A developer with access to live customer data is often a processor under GDPR, and a careful one raises it without being asked.

If the client has since switched developers, ask how the handover went. It's the best test of whether you could move on without this person. I've written about what a clean handover takes in the guide to switching developers mid-project.

8. How has the software held up since launch?

Many references get contacted shortly after a project, while everything still feels new. So ask how long the software has been live and how it's gone since. Have there been many bugs? Who fixes them, and how fast? Is the developer still reachable?

The strongest answer is software that's still running and still being improved, either by the same developer or by a new one who took over without drama. The weakest is a system someone else rebuilt from scratch soon after. If that happened, ask why. Sometimes it was the developer's fault. Sometimes the business simply changed direction.

9. Would you hire them again for the same kind of project?

Save this for last and stress "the same kind of project". Plenty of references will happily use a developer again for small jobs but hesitate about anything big. That difference matters if your project is the big one.

Follow up with "what would you do differently if you started over?" The answer is often as much about the client as the developer: a clearer brief, regular check-ins, a tighter contract. That's free advice for your own project. Finish with "is there anything I should have asked?" It catches whatever the reference wanted to say but never got the chance to.

How to read the answers

After two or three calls you'll have enough notes to see a pattern. Judge the pattern, not any single answer.

• Specific stories outweigh adjectives. "She always replied the same day" says more than "she was lovely to work with".
• One lukewarm reference isn't automatically a problem. Ask yourself whether the criticism touches anything that matters for your project.
• The same reservation from two references is a pattern. Raise it with the developer and listen to how they explain it.
• A reference who admits their own brief was vague is often the most credible one you'll get.

What references can't tell you

References are usually picked by the developer, so the absence of warning signs isn't proof. Most clients also can't judge code quality. They can tell you whether the software works today, not whether it'll be easy to build on three years from now.

When a lot is riding on the decision, combine references with something you can see for yourself. A paid trial project shows how the developer works with you specifically. An independent code review by another developer covers what references can't.

Be honest with yourself about what the references show, too. If every past project is far smaller than yours, or you need design, copy and development from a full team at the same time, a single freelancer probably isn't the right fit. That includes me.

Next steps after the reference check

Once references are done, you usually need three things: a final conversation with the developer about what you heard, a written contract and a plan for the first weeks.

Bring a couple of the references' reservations to that final conversation. How a developer reacts to criticism is an answer in itself. Then comes the contract. My freelance developer contract checklist covers ownership, payment terms and termination, so what you learned from question 7 ends up in writing.

If you want to see how I work, from a paid fixed-price discovery phase to ongoing maintenance, take a look at my services and how a project with me runs.

Frequently asked questions

What if a developer won't give you any references?+

Ask why first. Some developers work under NDAs and can't name certain clients, which is a fair explanation. In that case, ask for a reference from a different project, a former agency partner, or a piece of work you can inspect yourself. A developer who can't or won't show you anything at all deserves caution.

How do you vet a developer who has no references yet?+

Test instead of asking. Start with a small, paid task with a clear scope and a fixed price, then judge the collaboration afterward. A newer developer can be very good, but you're carrying more risk, so keep the first project small enough that you could live with it going wrong.

Can reviews on Upwork, Malt or Google replace a reference call?+

No, they're a useful supplement but not a replacement. Reviews are short, often written right after delivery, and rarely explain how problems were handled. Use them to spot patterns and to find past clients you could contact. Answers to follow-up questions only come from a real conversation.

How do you check references for a developer who worked at an agency?+

Ask the reference exactly what that developer did personally. Agency projects usually involve a project manager, a designer and several developers, so the client's impression covers the whole team. That's still useful, but the questions about communication and accountability say less about the individual. Ask for at least one reference from a project they ran on their own.