How to Know If Your Dev Team Is Lying to You

Every founder we’ve pulled out of a stalled build heard the same three words for months: “we’re almost there.” Four rescues in, the pattern is boringly consistent. And here’s the part that catches people off guard: most of those teams weren’t lying. They believed it.

So let me take the word “lying” apart before we start, because it changes what you do about this.

When a founder tells me their dev team is lying, they picture someone who knows the truth and hides it. That happens, but it’s rare. Far more often, the team genuinely believes what they’re telling you. They think they’re 90% done. They’re wrong, and they don’t know they’re wrong, and now you’re wrong too, because you believed them.

That’s more dangerous than a straightforward liar, not less. A liar can be caught. Someone who’s fooled themselves will pass you their false confidence with a completely clear conscience, and defend it when you push, because to them it’s just the truth. So the job isn’t detecting deceit. It’s detecting the gap between what feels done and what is done, and that gap is measurable without a shred of technical knowledge.

The Only Distinction That Matters

There are two kinds of progress, and telling them apart is the whole game.

Demo progress is what you’re usually shown. Someone who built the thing drives it, on their machine or a controlled environment, down a path they’ve walked a hundred times. It looks finished. It feels finished. It is not evidence of finished.

Real progress is different in three specific ways: you can use it yourself, unsupervised. It’s deployed somewhere real users could actually reach. And it holds together when you do something they didn’t rehearse.

The last 10% is where this lives. The visible parts really might be 90% done. But the invisible 90% of the work (what happens when a payment fails, when two people click at once, when the input is garbage, when it’s under real load) hasn’t started. So “we’re almost there” can be said with total sincerity, month after month, because it’s true about the part they can see and false about the part they can’t.

The sharpest version I’ve seen: a fitness platform, weeks from a launch date when we were brought in to advise. The mobile app looked great in a demo. Behind it there was, quite literally, no backend at all. The plan had been for the phones to talk to each other directly, an architecture that was never going to hold. The impressive part was the part you could see. The part that makes a product real hadn’t been started.

The Questions That Cut Through It

You don’t need to catch anyone out. You need to ask, and watch what happens.

On progress. “Can I open it and use it myself, right now?” Not a demo, a URL, on your own device, nobody driving. “What’s the complete list of what’s left?” A healthy team gives you this in ten minutes, roughly ordered, with honest uncertainty attached. A team in trouble gives you vagueness: “just some polish,” “a few edge cases.” “When did you last deploy where real users could reach it?” If the honest answer is “we haven’t yet” months in, the project hasn’t reached the starting line of the part that’s actually hard.

On trade-offs. “What did we decide NOT to build, and why?” Tells you whether anyone’s protecting your scope and budget. A good answer names a real cost: “we skipped X because it triples the timeline.” A blank look means nobody’s guarding the edges. “What did you build fast that we’ll want to redo later?” The correct answer is never “nothing.” Every fast build trades future cost for present speed, and a good team knows exactly where they cut corners on purpose.

On risk. “What’s the worst thing that could happen to our users’ data, and what stops it?” You’re not auditing the security, you’re checking whether it was ever considered. A real example of why this earns its place: on one product, GDPR meant adding a “delete all my data” option, so a developer added a Delete Company button in settings. Technically correct, requirement met. Then a curious user clicked it, and the whole company vanished, invoices, drivers, history, all of it. No hacker, no malice, and no confirmation dialog either. “What happens when [something important] breaks at 2am?” A good team has an answer, because things do break and they’ve planned for it.

How to Read Any Answer

You’ll never fully verify the facts. So grade the delivery instead, on three axes: clarity beats vocabulary (a good developer can explain almost anything at the right altitude without dumbing it down), trade-offs beat pure upside (any answer that’s all benefit and no cost is incomplete), and honesty beats confidence (“I’m not sure, let me check” beats a smooth reply that turns out wrong).

Activity Is Not Progress

The most convincing false signal isn’t a lie. It’s motion. Lots of it.

A team can be genuinely busy and genuinely stuck at the same time. The only measure that can’t be faked is a working thing you can use that does more this week than last. If the honest problem turns out to be that everything just takes longer than anyone expected, that might not be dishonesty at all. There are real structural reasons software slows down, and knowing them helps you tell a stuck team from a struggling one.

What to Do If the Answers Worry You

Investigate, don’t accuse. “Are you lying to me?” gets you a defensive denial. “Can you walk me through using the live version myself?” gets you the truth by demonstration.

Get an outside read. An independent senior engineer, someone with no stake in the answer, can assess in a few days what’s real and what’s theatre. It’s the cheapest insurance a non-technical founder can buy.

Reset the definition of done. Replace “almost there” with a written, specific list and payment tied to shipped software rather than time passed. A team that’s actually close will happily agree. A team that isn’t will resist, and the resistance tells you what you needed to know.

Sunk cost is brutal here. You’ve paid a lot, waited long, and starting over feels like admitting the whole thing was wasted. But the money’s already gone either way. The only real question left is whether the next dollar has better odds here, or somewhere else.

The Pocket List

Screenshot this. Bring it to your next update.

• Can I use the live version myself today?
• What’s the complete list of what’s left?
• What did we decide not to build, and why?
• What did you build fast that we’ll redo later?
• What’s the worst that could happen to user data, and what stops it?
• What happens when [important thing] breaks at 2am?

A good team is glad you asked. A team that bristles at fair questions has just shown you how the rest of the relationship is going to feel. Four of the builds we’ve taken over began exactly there, with a founder who couldn’t get a straight answer to the questions above. A second opinion is cheap next to another month of not knowing.