What References Should You Request from App Developers?

A productivity app launched with huge expectations—backed by serious investment, built by a team that looked perfect on paper, and designed to compete with the big players. Six months after launch it had crashed and burned. Not because the idea was bad, but because the development team couldn't deliver what they'd promised. The founders had checked the agency's portfolio, sure, but they never actually spoke to previous clients. They never asked the hard questions. And it cost them everything.

I mean, choosing an app developer is one of those decisions that keeps business owners up at night, isn't it? You're about to hand over a significant chunk of your budget—sometimes tens or even hundreds of thousands of pounds—to someone who's going to build the digital face of your business. And here's the thing: their portfolio might look brilliant, their sales pitch might be convincing, but none of that tells you what its actually like to work with them day-to-day.

That's where developer references come in. Actually speaking to people who've been through the process with this team gives you insights you simply cant get anywhere else. You'll learn how they handle problems when things go wrong (and trust me, things always go wrong at some point). You'll discover whether they stick to deadlines and budgets or if there's always another invoice coming. You'll find out if they're responsive when you need them or if they disappear for days at a time.

The difference between a good reference check and a bad one can literally be the difference between launching a successful app and wasting six months and £50,000 on something that never works properly

But here's what I've noticed over the years—most people don't know what questions to ask when checking references. They make a quick call, ask if the developer was "good to work with," get a vague positive response, and think they've done their due diligence. That's not enough. Not even close. This guide will show you exactly what you need to ask, what warning signs to watch for, and how to separate genuine developer talent from well-marketed mediocrity.

Why Developer References Actually Matter

Look, I get it—asking for references feels a bit awkward. Its like you're interviewing someone for a job and suddenly you need to check if they're actually telling the truth about their experience. But here's the thing; when you're about to hand over tens of thousands of pounds to build something as important as a mobile app, those references aren't just nice to have. They're your best defence against making a really expensive mistake.

Over the years I've seen projects go sideways in ways that could have been spotted early on if someone had just picked up the phone and asked a few questions. A developer's portfolio might look impressive—sure, they've got beautiful screenshots and polished case studies—but what you don't see is whether they delivered on time, how they handled problems when things went wrong, or if their code actually holds up six months after launch. References fill in those gaps.

The truth is, most developers aren't trying to deceive you. But there's a big difference between a team that can build something that works on day one and a team that builds something maintainable, scalable, and genuinely fit for purpose. References help you understand which one you're getting.

What References Actually Tell You

• How the developer handles unexpected technical challenges
• Whether they stick to budgets and timelines or constantly ask for more money and time
• Their communication style when things get stressful
• How the app performs months or years after delivery—not just at launch
• Whether they provide proper documentation and knowledge transfer
• How they respond to bugs and support requests post-launch

You know what? Some developers will hesitate to provide references, and that alone tells you something. The good ones—the ones who've built strong relationships with their clients—they'll happily connect you with people who can vouch for their work. Because they know those conversations will only strengthen your confidence in working with them.

What to Ask Previous Clients

Right, so you've got a list of references and you're ready to make some calls—but what do you actually ask these people? I mean, you can't just ring them up and say "was the developer good?" and expect to get useful information. After all these years working with clients, I've learned that the questions you ask make all the difference between getting genuine insight and just hearing what the developer wants you to hear.

Here's the thing though; most people are too polite when giving references. They'll tell you everything was fine even when it wasnt. So you need to ask questions that get past the polite surface and reveal what working with this developer was really like. Ask open-ended questions that require detailed answers—not yes or no questions that let people off easy.

Questions That Actually Tell You Something

Start with the basics but dig deeper. Ask what the project was, how long it took, and what the final budget came to compared to the original estimate. But then—and this is where it gets interesting—ask what changed during the project? Every app project has changes, its just how development works. What you want to know is how the developer handled those changes. Did they communicate well? Were they flexible or did they get defensive?

Ask about problems because there are always problems. How did the developer handle bugs after launch? Did they stick around for support or disappear once they got paid? I've seen both happen more times than I can count, and its a massive indicator of how they'll treat you.

The Questions Nobody Thinks to Ask

Here's what really matters; ask if they would hire this developer again. Simple question, right? But watch how people answer it. If there's any hesitation at all, that tells you something. Also ask what they wish they'd known before starting the project—this question almost always reveals something useful that the developer hasn't mentioned.

You should also ask about the developers team and who actually did the work. Was it the person you're talking to now or was it outsourced? This happens more than you'd think, especially with smaller agencies trying to punch above their weight.

Ask the reference: "If you were starting this project again tomorrow, what would you do differently?" Their answer will tell you loads about potential pitfalls and whether the developer helped them avoid common mistakes or just took their money and built what they asked for.

Don't forget to ask about post-launch support. Did the app actually work when it launched? Were there major bugs? How quickly did the developer respond to issues? An app that crashes on launch day is a nightmare I wouldn't wish on anyone, but it happens when developers rush to hit deadlines without proper testing.

Finally, ask about communication style and frequency. Some developers go silent for weeks then dump a bunch of work all at once. Others send daily updates. Neither is necessarily wrong, but you need to know what you're getting into so it matches your expectations and working style. The worst projects I've seen always had communication breakdowns at their core—good developers know this and make communication a priority, not an afterthought.

Red Flags When Checking References

Right, let's talk about the warning signs that should make you pause—or run in the opposite direction. After checking hundreds of references over the years, I've learned to spot the red flags pretty quickly. Some are obvious, some aren't.

If a previous client seems hesitant or takes ages to respond to your questions, that's your first clue something went wrong. Happy clients want to talk about their positive experiences; they're usually quite enthusiastic about it actually. When someone gives you vague answers or keeps saying "it was fine" without any detail, they're probably being polite about a less-than-stellar experience. I mean, nobody wants to slag someone off completely, but you can tell from their tone.

The Most Common Warning Signs

Watch out for these specific issues—they've caused problems for nearly every client I've seen who ignored them. If the reference mentions the developer disappeared for days without communication, that's a massive red flag. Mobile app projects need constant dialogue; things change quickly and decisions need making. A developer who goes silent is basically leaving you stranded.

Budget overruns are another big one. Sure, sometimes projects genuinely need more work than anticipated, but if every reference mentions the final cost being way higher than quoted? That's a pattern you cant ignore. Same goes for timeline issues—one project running late could be bad luck, but multiple projects behind schedule suggests poor planning or overpromising.

Here's what really concerns me though: if you notice the reference talks about the app working initially but then having loads of bugs after launch. That suggests rushed testing or poor quality control, and fixing those issues post-launch costs way more than doing it properly the first time. Trust me on that one.

Portfolio Projects vs Real Client Work

Here's something I see all the time—developers showing off their portfolio with beautifully designed apps that look absolutely perfect. Clean interfaces, smooth animations, all the bells and whistles. But here's the thing; theres a massive difference between a portfolio project and an app that's been through the trenches with real users and real business constraints.

Portfolio projects are built in ideal conditions. No budget restrictions, no tight deadlines, no difficult clients changing their minds halfway through. The developer gets to choose exactly what features to build and can spend weeks perfecting that one animation. Real client work? That's a different story entirely—you're working with limited budgets, shifting requirements, and you need to make tough decisions about what's actually important vs what's just nice to have.

When you're checking references, you want to know about projects where real money was on the line. Ask about apps that are actually in the App Store right now, being used by real people. How many downloads does it have? What's the retention rate like? Has it been maintained and updated over time, or was it just built and abandoned? These questions tell you way more than a pretty screenshot ever could.

The best indicator of future performance is past performance under similar conditions

I mean, anyone can build something beautiful when they have unlimited time and resources. The real test is whether a developer can deliver quality work when things get messy—and trust me, they always get messy at some point. Look for developers who can show you projects that have been live for months or years, not just prototypes that never saw actual users. That's where you'll find out if they can really do the job you need doing.

Technical Competence and Problem-Solving Skills

When you're checking references, you need to dig into the developer's actual technical abilities—not just what they say they can do. I mean, anyone can claim they're brilliant at React Native or Swift, but can they prove it? Ask the reference how the developer handled technical challenges during the project. Did they find elegant solutions to complex problems or did they just bodge things together and hope for the best?

Here's what I always tell people to ask about: How did the developer approach performance issues? What happened when unexpected bugs appeared? Did they explain technical decisions in a way that made sense or did they hide behind jargon? These questions reveal so much about how someone actually works. And you know what? The best developers are honest when they hit roadblocks—they dont pretend everything's perfect all the time.

How They Handle Technical Debt

One thing thats really telling is how a developer manages technical debt. Sure, sometimes you need to cut corners to meet a deadline, but did they come back and fix those shortcuts later? Ask the reference whether the code was maintainable after handover. Could their internal team make changes without everything breaking? I've seen too many projects where developers delivered something that worked on launch day but became a nightmare to update six months later.

Problem-Solving Under Pressure

You also want to know how they performed when things went wrong. Because things always go wrong, trust me on this. Did they panic and disappear? Did they blame everyone else? Or did they calmly work through the issue and find a solution? The way a developer handles pressure tells you more about their competence than any qualification or certification ever will. Ask about specific examples—vague answers usually mean the experience wasnt great.

Communication and Project Management Style

Here's what nobody tells you about app development—the actual coding is often the easy part. I mean it. The bit that usually derails projects? Poor communication and messy project management. When you're checking references, you need to dig into how the developer keeps clients informed, how they handle changes (because trust me, there will be changes), and whether they stick to deadlines without constant chasing.

Ask their previous clients how often they received updates. Was it weekly? Daily during crunch periods? Or did they have to constantly follow up asking "whats happening with my project?" The best developers I know have a rhythm to their communication—they dont wait for you to ask, they proactively share progress, blockers, and next steps. And when something goes wrong (which it will at some point) how quickly did the developer flag it? Did they present solutions or just problems?

Project Management Tools and Processes

Find out what tools they used for project management. Did the client have access to see real-time progress or were they kept in the dark? Some developers use Trello, others prefer Jira or Asana, but the specific tool matters less than whether it was actually used properly. I've seen projects fall apart because the developer insisted everything was "on track" right up until the deadline passed. References should be able to tell you if the developer set realistic expectations or overpromised and underdelivered.

Handling Scope Changes and Disagreements

This is where you learn the truth about someone. Ask how the developer handled scope changes—did they document them clearly, explain the time and cost implications, and get sign-off? Or did they just say yes to everything and then complain about it later? Actually, ask about disagreements too; every project has them. Did the developer explain their technical reasoning in a way the client could understand, or did they hide behind jargon and dismiss concerns?

When checking references, ask specifically: "If you could change one thing about how this developer communicated with you, what would it be?" The answer to this question tells you more than any glowing testimonial ever could.

Budget and Timeline Reliability

Right, let's talk money and deadlines—because this is where a lot of app projects go properly sideways. When you're checking references, you need to ask straight questions about whether the developer stuck to their original budget and timeline. I mean, nobody expects perfection here (app development is complex and things change), but there's a big difference between a 10% overrun and a project that costs twice as much and takes three times as long.

Ask the reference client if the developer gave them a clear breakdown of costs upfront;did they know what they were paying for? Were there hidden fees that appeared later? And here's the thing—you want to know how the developer handled scope changes. Because scope will change, it always does. Did they clearly communicate the cost and time implications before doing extra work, or did they just add it to the bill at the end? That transparency matters more than you might think.

Timeline reliability is just as important as budget. Sure, delays happen—App Store review processes can be unpredictable, third-party APIs sometimes dont work as expected, and testing always takes longer than planned. But a good developer builds buffers into their timeline and keeps you informed when delays crop up. They don't just disappear for weeks and then reappear with excuses.

Questions to Ask About Budget and Timeline

• Did the final cost match the original quote, and if not, why?
• Were additional costs communicated clearly before the work was done?
• How did the developer handle unexpected technical challenges that affected the budget?
• Was the project delivered on time, and were delays communicated early?
• Did you feel the billing was transparent and fair throughout the project?
• Would you budget the same amount if you were starting again, knowing what you know now?

Look, app development isnt cheap and it takes time. But you deserve to work with someone who respects your budget constraints and values your time as much as their own.

Conclusion

Look—checking developer references isn't exactly the most exciting part of building an app, but its absolutely one of the most important. I mean, you wouldn't hire someone to renovate your house without asking a few questions about their previous work, would you? The same logic applies here; maybe even more so considering how much money and time goes into app development.

The thing is, a good reference check does more than just confirm someone can write code. It tells you how they handle problems when things go wrong (and trust me, things always go wrong at some point). It shows you whether they communicate well under pressure. Whether they stick to budgets. Whether they actually care about the projects success beyond just collecting payment.

After years of doing this work, I've learned that the developers who are confident in their abilities are usually quite happy to provide references—they know what previous clients will say. The ones who make excuses or seem reluctant? That's when you need to pay attention. Your gut feeling matters here.

So take the time to make those calls, send those emails, dig into portfolios and ask the awkward questions about missed deadlines or budget overruns. Yes it takes effort; yes it might feel a bit uncomfortable at first. But spending a few hours on proper reference checking now can save you months of headaches and potentially tens of thousands of pounds down the line. And honestly? Any developer worth their salt will respect you more for doing your due diligence properly. It shows you're serious about this project and that you understand what's at stake.