What to Ask a Reference Before You Hire a Dev Partner

For: A seed-to-Series A founder in Dubai who has shortlisted two dev partners, received glowing written testimonials from both, and is about to sign — but has never personally run a reference call on a technology vendor before

A dev partner's reference list is pre-screened to say yes. Your job on the call is to find the one client who has actually pushed the engagement past the comfortable phase — through a missed milestone, a disputed change order, or a security review that got tense — because a reference who reports zero friction has almost certainly never tested the vendor under load. This post gives you 15 questions to do that in a 30-minute call, structured so you can score both shortlisted partners on the same axes before you wire the deposit.

Context for why this matters: unclear requirements (39%), scope creep (33%), and communication breakdowns (25%) are the top causes of software project failure — technical problems rank last (Standish Group, via Raft Labs). Poor vendor selection alone drives 29% of outsourced project failures (Gitnux). Every question below is designed to probe one of those failure modes, not to confirm a testimonial.

Before the call: three things to set up in five minutes

• Ask for three references, not two. Specifically request: one project that went well, one that had a difficult phase, and one that finished in the last 90 days. A vendor that cannot produce a difficult-phase reference either has no long-term clients or is filtering hard.
• Confirm the reference actually paid for the work. Founder-friend testimonials, unpaid pilots, and equity-swap builds all read the same in a case study but tell you nothing about invoice disputes or change-order behaviour.
• Send the reference three questions in advance. Not all fifteen. Just enough that they arrive prepared with specifics instead of adjectives. "Great to work with" is not signal. "They pushed back on our auth flow in week three and we're glad they did" is.

The 15 questions

1. Walk me through the first serious disagreement you had with them. What was it about and how did it end?

Why it matters: Every real engagement has a disagreement by month two — scope, estimate, an architectural call. If the reference cannot name one, they are either sanitising or the project was too small to matter.

Good answer: Specific, dated, and describes a resolution mechanism ("We escalated to their delivery head, they redid the estimate, we split the cost of the rework 50/50"). The reference sounds like they respect the vendor more for how it was handled.

Red flag: "Honestly, we never really disagreed on anything." Or a vague answer about "communication issues early on" with no resolution described.

2. Was there a missed milestone? Which one, and what caused it?

Why it matters: Large IT projects run 45% over budget and 7% over time on average, delivering 56% less value than predicted (McKinsey / University of Oxford). Slippage is the norm; the useful signal is how the vendor communicated it.

Good answer: "They flagged a two-week slip at the end of sprint four, showed us the burndown, gave us three options — cut scope, add a developer at their cost, or extend." Early warning + options.

Red flag: "They were basically on time" (unlikely and unverifiable) or "We found out the week of the demo" (fatal — that pattern will repeat with you).

3. How many change orders were raised, and who initiated the first one?

Why it matters: Change orders are neutral instruments; behaviour around them is not. A vendor that never raises change orders is absorbing scope creep and will run out of goodwill by month four. A vendor that raises one every sprint is either underquoting the SOW or padding.

Good answer: Three to six over a six-month build, most initiated by the client adding scope, priced transparently.

Red flag: "None, they just kept building whatever we asked." That vendor is losing money on the client and will cut corners on yours to make it back.

4. Did their IP or exit clauses need lawyer intervention? What was contested?

Why it matters: For a Dubai founder committing AED 200K–500K, this is the single most expensive thing to discover after signing. Standard vendor MSAs often keep background IP, reusable components, or claim licence-back rights over the delivered code.

Good answer: "We negotiated the background IP definition and the source-code escrow trigger. They accepted our redlines within a week."

Red flag: "We just signed their template" (means the reference never stress-tested it) or "It took a month and we still weren't happy" (means you will spend legal fees to get to the same place). Get your own lawyer to review the actual contract regardless — this question just tells you what you are walking into.

5. Who was on the team in month one, and who was on the team in month six?

Why it matters: Bait-and-switch is the most common offshore complaint. The senior architect in the sales pitch quietly disappears; two junior engineers you never interviewed are billing full rate by month three.

Good answer: Named continuity on tech lead and PM. Junior changes explained and pre-approved.

Red flag: "Honestly, we lost track" or "The lead changed twice and we weren't told in advance."

6. How did they handle the first production incident?

Why it matters: Everyone ships a bug that takes down checkout at 11pm on a Saturday. Response behaviour under that specific stress is impossible to fake in a proposal.

Good answer: A named on-call engineer responded within an SLA, a post-mortem was written, a preventative change went into the next sprint.

Red flag: "We had to WhatsApp the founder" or "They fixed it but we never got a root-cause analysis."

7. What did their handover look like — or is there no handover because you're still with them?

Why it matters: A partner that cannot describe a clean handover is a partner engineered for lock-in. You want to know the code, credentials, infra, and documentation transfer cleanly to your in-house team or another vendor whenever you decide.

Good answer: README-driven repos, an architecture decision record, credentials in a shared vault you own, a two-week overlap with your engineers.

Red flag: "We don't really have documentation — we just ask them."

8. What percentage of your original scope actually shipped, and what got cut?

Why it matters: Scope creep drives 33% of failures (Standish Group). But under-shipping matters too. If the answer is "100% of scope shipped", the SOW was probably written after the build.

Good answer: "About 70% of the original SOW, we cut the admin panel to launch faster, added it in phase two." Shows the vendor was helping prioritise, not just executing.

9. How was their code reviewed, and by whom on your side?

Why it matters: Offshore code that no in-house engineer ever reviewed is a technical debt bomb. You want to know the vendor invited scrutiny and made it easy — not that they resisted it.

Good answer: PR-based workflow in your GitHub org, your CTO or a fractional CTO reviewing, linting and test coverage gates enforced.

Red flag: "They sent us builds" or "We didn't have a technical person, we just trusted them." You do not want to be the next reference giving that answer.

10. What did their security posture look like in practice, not in the pitch deck?

Why it matters: Especially relevant if you handle payments, health, or KYC data under UAE PDPL or a sector regulator. Certifications on a website mean less than daily behaviour.

Good answer: Least-privilege access, secrets never in Slack, laptops with disk encryption, offboarding within 24 hours of a developer rolling off.

Red flag: "They sent us the ISO cert" — that is not an answer to the question. Have a security-qualified advisor review actual controls; this question just filters obvious problems.

11. Did they ever tell you not to build something?

Why it matters: Body-shop vendors will build anything you pay them to build, including features their own data suggests will not work. A product-minded partner pushes back.

Good answer: A specific instance — "We wanted a native app, they pushed us to a PWA first, saved us four months."

Red flag: "They built exactly what we specified" — polite for "they had no opinion."

12. If you were starting over tomorrow, what would you change about the contract?

Why it matters: This is the single most valuable question on the call. It gives the reference permission to be honest without attacking the vendor, and it hands you a free redline list.

Good answer: Specifics — "Tighter definition of what a sprint deliverable means," or "An earlier trigger on the source-code escrow," or "A cap on rate increases at renewal."

Red flag: "Nothing, honestly." Nobody has ever run a real engagement and had nothing to change.

13. How did invoicing work — any surprises?

Why it matters: Time-and-materials invoicing without governance produces month-four shock. Fixed-price without a change process produces quality shortcuts in the final sprint.

Good answer: Weekly time reports, monthly invoices matching estimates within a stated tolerance, no line items the reference cannot explain.

Red flag: "There was one big invoice we argued about" that was not resolved to the reference's satisfaction.

14. Have you referred them to anyone else? Did that engagement go well?

Why it matters: A reference willing to stake their own reputation twice tells you more than any testimonial. A reference who has referred and had it go badly will usually tell you exactly why if you ask directly.

Good answer: "I referred two other founders. One is still working with them, one wasn't a fit and moved on amicably."

15. What are they genuinely bad at?

Why it matters: Every vendor is bad at something. A reference who cannot name one weakness is not a useful reference. Ask it flat, wait through the pause, do not fill the silence.

Good answer: "Design — we brought our own designer." Or "Enterprise sales enablement — they build product, they don't do procurement paperwork well."

Red flag: "Nothing comes to mind" — end the call, this reference is coached or captive.

Scoring the two shortlisted partners against each other

After both calls, rate each vendor 1–5 on: disagreement handling, missed-milestone communication, change-order discipline, IP/exit terms, team continuity, incident response, handover cleanliness, scope realism, code review posture, security behaviour, product opinion, contract redlines, invoicing predictability, willingness to be re-referred, and self-awareness. If a vendor scores under 3 on IP/exit, security, or handover, do not sign regardless of the other scores — those three are the ones that turn into lawsuits, breaches, and lock-in.

The UAE IT services market is on track to nearly double from USD 20.24 billion in 2025 to USD 37.69 billion by 2030 (Mordor Intelligence), which means the supply of Dubai-facing dev partners is growing faster than most founders can evaluate them. A structured reference call is the cheapest filter you have.

What this process cannot tell you

Reference calls are backward-looking. They tell you how the vendor performed on someone else's problem, with someone else's team, in someone else's regulatory context. They do not tell you how the vendor will handle your auth complexity, your data-residency constraint, or your co-founder who changes his mind about scope weekly. For that, run a paid two-week discovery or a small pilot before committing to the full build. Treat the reference calls as necessary but not sufficient.

How CodeNicely can help

If you are a founder in Dubai evaluating dev partners for a regulated product — fintech, health, lending, logistics — a useful comparison point is Cashpo, where we built the KYC pipeline and AI credit-scoring layer for a lending product that had to satisfy both regulator scrutiny and week-one production traffic. What that engagement looked like from the client's side — the change orders raised, the security controls actually implemented, the handover documentation — is exactly what a good reference call would surface, and we are happy to put you on a call with the founder directly rather than send you a written testimonial. The same applies for our work with GimBooks (YC-backed accounting SaaS) if your product is closer to horizontal SMB software. See our Dubai practice page for how we structure engagements for UAE-based founders, including IP terms and escrow.

Frequently Asked Questions

How many references should I ask for before signing a dev partner?

Three at minimum, and specifically request one project that went well, one that had a difficult phase, and one that finished in the last 90 days. Two glowing references from picked-favourite clients are the default; the difficult-phase reference is what tells you whether the vendor handles friction professionally or hides from it.

Should I do reference calls before or after the technical deep-dive?

Before. The technical deep-dive is expensive for both sides and should only happen with vendors who pass the reference stage. If a reference tells you the vendor missed milestones without warning or fought over IP, the technical deep-dive does not fix that — those are engagement-design failures, not technical ones.

What if a vendor refuses to give me a difficult-phase reference?

Treat that as a data point. Some vendors will honestly say "our long-term clients are still under NDA" — that is fair for regulated sectors. But a vendor that cannot name any client who experienced any friction has either never taken on a hard project or is filtering references so aggressively that you cannot trust the ones you do get.

How much should a founder in Dubai budget for a shortlist-and-select process before signing?

The cost of the selection process itself is mostly your time — figure 15–25 hours across two shortlisted vendors including reference calls, technical deep-dive, and legal review of the MSA. The variables that move the actual engagement budget after signing are scope clarity, number of third-party integrations, data-residency requirements, and whether you have an in-house technical reviewer. To turn a range into a real quote, a vendor needs to see your PRD or a discovery output, your target launch window, and your compliance context — a scoping call with CodeNicely is the fastest way to get there.

Do I need a lawyer to review a dev partner contract in the UAE?

Yes. IP assignment, source-code escrow, data-residency, jurisdiction clauses, and termination terms are the five places offshore MSAs most commonly disadvantage the client, and none of them are things a founder should self-negotiate on a AED 200K–500K commitment. This post is not legal advice — get a UAE-qualified commercial lawyer to review the specifics of your contract.