What a Developer Really Thinks When You Ask "It's Almost Done, Right?"

"It's almost done, right?"

In 18 years, this has been the hardest question to answer. I know it isn't asked in bad faith. And yet developers always pause for a beat before responding. Here's why.

"Almost" Isn't a Measured Number

"Almost done" carries a hidden assumption: that progress is something you can see.

A screen loads, a button clicks, data shows up in a list. From the outside, "looks done to me" is a natural read. Most of what's visible really is finished.

The problem is that in software, the visible part and the actual amount of work left are not proportional.

The Visible 90%, the Invisible 90%

Take one feature: a sign-up screen.

What you see is a few input fields and a button. That part gets built quickly. What's hidden behind it looks like this:

• What happens if the email is already registered
• What if the password doesn't meet the rules
• What if the verification email never arrives
• What if the user closes the window mid-signup
• What if the same email hits submit twice at once

The screen looks "almost done," but it only becomes usable once each of these is handled. If what you saw were all there was, it would've been finished long ago.

The Longest Stretch Is From "Almost" to "Done"

The distance between "looks like it works" and "ready to hand to a real user" is the most underestimated stretch in software.

A demo is fast — you only need one happy path to pass. But a real service has to survive every unhappy path. Error handling, edge cases, real data, performance, security — this stretch looks like "wrapping up," but it's actually half the job.

That's why "yes" is hard to say to "it's almost done, right?" By what's visible, yes. By what's actually left, not even close.

How to Ask Instead

"Is it almost done?" is really a question about progress. But it's a poor tool for finding out. These get a far more accurate answer:

"What actually works right now, end to end?" — not whether the screen loads, but the range that genuinely functions with edge cases handled.

"What's left on the list?" — instead of the vague "almost," this pulls out the remaining items. Developers can answer this one concretely.

"Can I see the current state?" — touching it beats hearing about it. Frequent check-ins on the actual build keep the "almost" gap from forming in the first place.

---

When a developer hesitates at "it's almost done, right?", they aren't hiding something. The word itself masks the work that's left. Progress is better measured by the number of edge cases handled than by the screen you can see. Change the question, and the answer gets accurate.