Every dev shop’s website has a testimonials page, and every testimonials page says roughly the same thing: “great communication, delivered on time, would work with them again.” That sentence is worth almost nothing. It’s the answer to a question nobody actually asked — “were they nice to work with?” — and it dodges every question that actually predicts whether your project will go the same way.
A real reference check is a phone call, not a quote you copy off a landing page. If a vendor offers you two or three past clients, take them up on it, and go in with a script that surfaces the stuff testimonials are designed to hide: scope creep, missed dates, and who was actually at the keyboard.
Who actually wrote the code
This is the question founders skip because it feels rude, and it’s the one that matters most. A lot of agencies sell you a senior architect in the sales call and then staff the build with whoever’s available — often a junior contractor or a subcontracted team you never meet. That’s not automatically a problem, but you need to know it’s happening, because it changes who you’re relying on when something breaks six months from now.
- “Did the person who sold you the project also write the code, or hand it off afterward?”
- “If you had a question mid-build, who answered it — the founder, a PM, or a rotating engineer?”
- “Did the same people who started the project finish it, or did you see turnover partway through?”
Turnover mid-project is common and not always a red flag — but if the reference can’t tell you who actually built their product, that’s worth knowing before you sign anything. It’s also the core of why direct access to the engineers matters: at a two-person shop, there’s no one to hand you off to. The people on your kickoff call are the people who will still be debugging your production issue at 11pm.
What scope actually looked like versus what was promised
Every project scope document is a hypothesis. The question isn’t whether it changed — it’s how the vendor handled the change, and who ate the cost.
- “What was in the original quote, and what ended up shipping? Were they the same thing?”
- “When something took longer than expected, did they tell you before or after it happened?”
- “Did ‘scope creep’ come from your side adding requests, or from the vendor discovering the original estimate was wrong?”
- “Were there change orders, or did extra work just get absorbed into a longer timeline without anyone naming it?”
The answer you’re listening for isn’t “nothing ever changed” — that’s rare and a little suspicious. You’re listening for whether the vendor flagged problems early and put a number on them, or let the client find out at the end that the budget had quietly doubled. A shop that tells you “we’re three weeks behind because the payment integration needed more testing than we scoped” is behaving well. A shop that goes dark for a month and then asks for more money is not.
What happens when something breaks after launch
Launch is the easy part to get a good review for — everyone’s excited, the demo works, the testimonial gets written that week. The real test is what happens two or three months later when a bug shows up in production or the client wants to add a feature the original architecture didn’t anticipate.
- “Did you use them again for a second phase, or hire someone else?”
- “When there was a bug after launch, how fast did they respond, and did you pay for that time?”
- “Could another engineer — not the original team — pick up the codebase and understand it? Did anyone ever try?”
- “Would you show me the actual app or admin panel they built, not just a screenshot?”
That last one is the cheapest, highest-signal question on this list. Ask to see the live product, or at least a screen-share of it running. A shop that’s proud of what it shipped will show you immediately. A shop that stalls, or shows you a Figma file instead of a working app, is telling you something.
Asking the questions that get honest answers
Two more things make these calls useful. First, ask for references from a project that’s at least six months old, not the one that just launched last week — you want to know how the code held up, not just how the demo went. Second, ask the vendor directly, before you even call their references: “Is there a project that didn’t go well? What happened?” Every shop with more than a handful of clients has one. A vendor willing to walk you through a project that went sideways — what broke, what they’d do differently — is giving you more useful information than five glowing testimonials combined.
At orithLabs we’d rather you ask these questions than take our word for anything. We’re a two-founder shop — Flutter apps with native Swift/Kotlin work where it’s needed, backends, admin consoles, AI features built with security in mind, and audits of codebases other teams left behind — and we can point you to shipped, running products like Crumb Count and Kompete rather than a highlight reel. If you’re mid-way through vetting a vendor, or trying to figure out why a stalled build stalled, happy to talk through what a reference check like this should actually turn up.