Why Your Developer Has Been "80% Done" for 3 Weeks

Your engineer may not be stuck at 80%.

You may be calling the feature 80% complete because its happy path is already visible. The button exists, the main action works, and the demonstration succeeds.

But a working happy path does not mean 80% of a production feature is complete. It means one scenario works.

The Hotel Keycard That Looks Finished

Imagine a hotel asks for a keycard system. In the first demonstration, a guest taps one card on one door. The light turns green and the door opens. Everyone can see the result, so the system feels nearly finished.

Then the real questions begin. What happens after checkout? What happens when a card is lost and reception creates a replacement? Does the old card stop working immediately? What if the guest changes rooms or two guests share one room?

The hotel also needs cleaning staff, maintenance access, emergency behavior, and a plan for interrupted power or connectivity. None of that makes the guest’s interface look larger. It remains one small interaction: green or red, open or locked.

The amount of visible interface does not reveal the amount of behavior underneath it.

A Demonstration Proves Only What It Exercised

Software teams confuse the same signals. A button appears and works once, so the feature is described as nearly complete. Real users repeat requests, lose connectivity, lack permission, close the page halfway through, and perform actions at the same time as somebody else.

External providers fail. An operation may succeed even though the response never reaches the screen. A user may return later and expect the product to remember the correct state. When money, access, data, or trust is involved, those are part of the feature, not decoration around it.

Invisible Work Still Needs Accountability

This is not an excuse for unexplained delay. Taking longer does not prove that valuable engineering is happening, and “there are many edge cases” is not a useful update.

A strong engineer should be able to name:

• the real situation that still needs to work;
• the user or business outcome that situation protects;
• what could go wrong if it is ignored; and
• how the team will prove the behavior works.

For example, “we are handling idempotency” is technically accurate but not very useful to a founder. “If the customer clicks Pay twice, they must not be charged twice” explains the protected outcome.

Use Scenarios, Not Visual Percentages

“The payment button works” is one scenario. “A declined payment gives the customer a clear next step” is another. “A repeated click creates one charge” is another. “A successful charge remains recorded even if the browser loses the response” is another.

That does not mean listing every theoretical failure. A social product and a banking product do not need the same protection. The scenarios should match the product’s real risks.

A feature is not done when the demo succeeds once. It is done when the real world is allowed to happen.