Checking references on a development company

A reference call is the cheapest evidence a buyer will ever get about a development company, and almost nobody spends it well. The failure is not that founders skip references. It is that they ask questions a satisfied customer can answer without thinking, then treat the resulting warmth as information. The people who check references for a living have measured what that produces: reviewing how contractor performance is recorded across the federal government, the US Government Accountability Office cited a Department of Defense Inspector General review finding that, for DOD contracts worth more than $5 million, 82 percent of performance assessments "did not contain detailed narratives sufficient to establish that ratings were credible and justifiable," 68 percent were overdue, and 39 percent were registered more than a year late (US Government Accountability Office, Federal Contractors: Better Performance Information Needed to Support Agency Contract Award Decisions, GAO-09-374, April 2009). A rating with no narrative underneath it is exactly what a polite reference call produces. Every question below exists to produce the narrative instead.

It gets worse before it gets better. The same GAO review — 62 contract solicitations and interviews with 121 contracting officials — counted how many federal contracts that required a documented performance assessment actually had one in fiscal year 2007. The answer was 7,007 of an estimated 22,904, or 31 percent, from 47 percent at the Air Force down to 13 percent at the Department of Homeland Security. These are organisations with a regulation, a purpose-built system and an auditor. If that is the state of recorded evidence where recording it is mandatory, the informal version available to a founder buying a first product is thinner still.

And yet the same report contains the argument for doing the work anyway. Asked what they actually relied on, GAO found that "most officials told us they found information from the prospective contractor's prior government or industry customer references — gathered through interviews or questionnaires — as the most useful source of past performance information." Professional buyers with a government-wide database at their disposal rated the phone call above the database. They also agreed on the standard: to be useful, the information "must be documented, relevant, and reliable." Relevant is the word buyers skip. A glowing reference from a project unlike yours is not evidence about your project.

Be honest about what a reference list is. A vendor gives you two or three customers they chose, who agreed in advance and were usually told what the call is about. You cannot remove that selection bias; you can defeat rehearsal. A prepared reference has a story ready about how the project went, and none ready about who left in month five or what the final four weeks looked like. Specificity is what a curated reference cannot manufacture on a call, so every question below asks for an event rather than an assessment.

What did they get wrong, and how did you find out? Ask it as one sentence, because the second half is the real question. Every project contains a wrong call, so a reference who cannot produce one is either protecting the vendor or was never close enough to know. The answer that should reassure you is dull: they raised it in the weekly, we changed the plan, it cost three weeks. The answer that should not is any version of finding out late — from a user, an invoice, a security review. A firm can be wrong often and still be safe to hire. A firm whose wrongness surfaces downstream cannot.

What did you have to chase? Every engagement has a chase list: the invoice breakdown, the staging environment, the design file, the answer to a question asked twice. It sounds like a small complaint rather than an indictment, so it produces specifics almost every time. The signal is not the length of the list but whether the items are administrative or substantive. Chasing an invoice is friction. Chasing a written decision the build depended on is a process gap, and process gaps travel between clients.

Who left the team mid-project, and what happened next? Somebody will. This is a labour-market fact rather than a comment on any firm: the US Bureau of Labor Statistics counted 3.1 million quits across the US economy in July 2026 at a quits rate of 1.9 percent, with the information sector at 1.0 percent and professional and business services at 1.8 percent (US Bureau of Labor Statistics, Job Openings and Labor Turnover Survey, July 2026, released 1 September 2026). Stack Overflow's 2025 Developer Survey shows the intent behind that monthly rate: 14.8% of respondents were strongly considering a change of role and 8.8% had voluntarily transitioned in the past year, against 45.6% not looking at all (Stack Overflow, 2025 Developer Survey: Work). Over a year-long build the question is not whether somebody leaves but what happened the week after, so ask for the replacement story. Two weeks and a handover document describes a firm with documentation. Two months and a re-explanation of the domain describes a firm where the system lived in one person's head.

Would you sign the same contract again, and which clause would you change? The first half gets a yes from nearly everyone on a reference list, which is why the second half is the question. A specific clause — the change-order mechanism, the payment schedule, the date IP assigns, the definition of done used for acceptance — tells you where that engagement hurt, and it is the most portable finding in the call, because you are about to sign the same paper. No clause at all, from someone who lived under it for a year, means they never read it or the project was too small to test it.

What did the last month look like? Beginnings are rehearsed and endings are not. The last month is where the unglamorous eighty percent either happened or did not: the data migration, the runbook, credentials moved into accounts the client owns, the walkthrough with the client's own engineers, known defects written down rather than discovered later. Ask whether the end was a date or a fade. A fade — invoices continuing while the work quietly thins — is the most common shape of a bad engagement, and a reference will often describe it in detail without ever calling it a problem. The handover you must receive is the itemised version of what you are listening for.

What do you own now, and could a different team pick it up? This separates a delivered system from a dependency, and it can only be asked of a customer. The answers worth hearing are concrete: the repository and its full history are ours, a new engineer got it running from the README inside a day, every third-party account is in our name. The answer that should stop the call is that they are not sure — two years on, not being sure means nobody ever tested it, and the test is what you are buying.

What did the firm talk you out of? The buyer's guide this article supports puts a version of that question to the vendor; put it to the reference as well and compare, because the vendor's answer is a prepared anecdote and the customer's is a memory of being contradicted. A reference who can describe being talked out of something, and still sounds faintly annoyed about it, has told you the firm gave up revenue to protect a delivery date — the most commercially expensive behaviour a development company can have.

What did your own team end up doing that you assumed the vendor would do? Every proposal has a silent line item on the buyer's side: somebody writes the copy, assembles the test data, chases the third-party approval, or makes the twenty product decisions nobody scheduled. A reference will tell you cheerfully, because they do not experience it as the vendor's failure. Read it as scope that was never named, then check whether the proposal in front of you names it.

How to read a reference who will only speak in generalities. Warm, positive and completely unspecific is the most common reference on earth, and it has three causes you have to separate: a confidentiality obligation, which is legitimate and normally announced rather than implied; distance, where the person was a sponsor rather than a participant and genuinely does not know who ran the weekly call; and discomfort, where the specifics exist and are not flattering. Distinguish them with questions whose honest answers are neutral — how often did you meet, who ran the meeting, what did you track work in, how long from first call to first working screen. A reference who cannot answer those was not close to the work, and their endorsement is worth what a stranger's is.

What it means when every reference is a project still in flight. It means nothing has been handed over, nothing has been operated by the customer alone, and nothing has survived a year of dependency upgrades and staff turnover. It is also the state in which a customer is most positive, because the relationship is live and the invoices are current. There are innocent explanations — a young firm, a long product cycle, a run of renewals — and one question tells you which you are looking at: ask for a completed engagement, at any size, from any year. If none exists, ask the individual engineers for one.

Ask for the opposite too: a reference from something long. Our platform consolidation for Cove, a US home-security device ecosystem, ran 24 months across an operator portal, a headless CMS and a data pipeline — so somebody there can describe what the second year was like and what got renegotiated. That is a far harder call for a vendor to stage than one about a launch. We also publish a short testimonial from Cove's product lead on that page, and it is worth saying what that is: a sentence we asked for and they approved. It is marketing. Ask for the phone call instead.

And one silence you should accept. Some of the best evidence about a firm is genuinely unavailable, and we are an example. A significant share of our work is delivered through other agencies under their brand, covered by the same non-disclosure we would sign with you, and we will not name those clients to win your project — because a firm willing to publish one client's work to win yours will publish yours to win the next one. How white-label delivery works sets out the arrangement. The test there is not whether a vendor will break an NDA for you, but whether they can describe the shape of the work without naming it, and whether the references they can offer are close enough to your project to be relevant.

Eight questions is one call, and the value is in putting the identical set to every firm on the shortlist so the answers are comparable: what did they get wrong and how did you find out; what did you chase; who left and what happened next; which clause would you change; what did the last month look like; what do you own now; what did they talk you out of; and what did your own team quietly absorb. Run that way, a reference call does the one thing no proposal can: it tells you what a firm is like on a bad week. What separates the top software development companies covers the signals readable in the sales conversation itself, and the full criteria for a top saas development company — including the one we publicly fail — sit on the page this article supports. Run them on us, and then call our references.