Here’s a pattern worth noticing: on a stalled project, the weekly update usually doesn’t get worse. It gets vaguer. Week 12 says “backend is basically done, moving to polish.” Week 16 says “just finishing up a few edge cases.” Week 20 says “almost there, tightening things up.” Nobody ever writes “we are three weeks behind and I don’t know why the payment webhook keeps failing intermittently.” That sentence is true. It’s also the one you never see, because it invites a conversation the team doesn’t want to have yet.
Founders who’ve been burned by a stalled build usually tell the same story afterward: they can point to the exact week the tone changed, but at the time it didn’t register as a problem. It just sounded like progress with fewer specifics. That’s the trap. A status update is supposed to tell you where the work stands. When it stops doing that and starts reassuring you instead, the update itself has become the signal.
Why teams reach for vague language
It’s rarely dishonesty. Most of the time it’s a developer who genuinely believes they’re 90% done, because the visible parts — the UI, the happy-path flow — do work. What’s left is the 10% that’s actually 50% of the effort: the auth edge case, the race condition under load, the third-party API that behaves differently in production than in the sandbox. That kind of work is hard to estimate and harder to explain to a non-technical client without sounding alarming, so it gets rounded up to “polishing.”
There’s also a incentive problem in a lot of agency setups. If the update goes out under a project manager who’s relaying status from a dev they don’t fully understand, precision gets lost in translation twice over. And if the shop is billing hourly or by milestone, there’s a quiet pressure to report momentum even when the actual state is “we’re stuck and re-approaching this.” None of this requires bad faith. It just requires normal human incentives operating without anyone checking the translation.
Phrases to listen for, and what to ask instead
You don’t need to learn to code to catch this. You need a short list of phrases that mean “I don’t have a number for you” and a follow-up question that forces one.
- “Almost done” — Ask: “Can I see it running end to end right now, even with rough edges?” If the answer is no, it’s not almost done, it’s almost demoable, and those are different milestones.
- “Just polishing” — Ask: “What specifically is left on the list, and how many of those items are unknowns versus known tasks?” Polishing implies a fixed, small list. If nobody can name the list, it isn’t a polishing phase.
- “Ran into a small issue” — Ask: “How long have you been on this issue, and what have you tried?” A small issue that’s been open for eight days isn’t small. It’s the actual bottleneck wearing a diminutive.
- “Should be ready by [date]” — Ask: “What’s the confidence on that date — is it a plan or a guess?” Dates stated without a because are usually optimism, not a schedule.
The common thread: every one of these questions asks for something concrete — a working build, a named list, a timestamp, a reason. Vague language can survive a vague question forever. It rarely survives a specific one.
What a healthy update actually looks like
The inverse is just as diagnostic. A team that’s actually on track tends to volunteer specifics without being asked: “we finished the checkout flow, here’s a video of it working, next up is the refund path which touches the same webhook so we’re budgeting extra time there.” That update names what’s done, shows evidence, and flags the risky part in advance instead of discovering it later and calling it a “small issue.” It also treats a delay as ordinary information rather than something to bury in soft language.
This is the standard we hold ourselves to at orithLabs, and it’s part of why we work as two engineers directly with the client rather than routing updates through a project manager who’s paraphrasing someone else’s work. If something’s not built yet, we say so — that’s not a confession, it’s just accurate status, the same way we’d want it reported to us. Our shipped work, like Crumb Count and Kompete, exists as something you can open and use, which is a different kind of evidence than a roadmap slide.
If you’re currently reading a status update and can’t quite tell whether “almost done” means two days or two months, that ambiguity is the finding, not a formality to wave past. Ask the specific version of the question. If you’re evaluating a stalled build, or just want a second set of eyes on whether a codebase is actually where your current team says it is, that’s the kind of conversation we’re glad to have — plainly, and before the deadline is the one breaking the news.