In plain language: every real software build has a hard part, and it usually arrives around 60 to 80 percent done, when everything is opened up and nothing demos well.
Why this matters
From the outside, that trough looks identical to failure: progress feels invisible, the demo is messier than last month's, and founders who don't know the trough is normal either panic, micromanage, or start shopping for a new team at the exact moment switching costs the most.
The common mistake
The trough and the trouble look identical from the outside. The only reliable telltale is communication frequency, which is why 'how do they behave in a bad week?' matters more than any portfolio.
How we approach it
Here's how to tell the difference without reading code: in a healthy hard part, communication gets denser, not thinner, you hear about problems the day they're found, with plans attached, and the board keeps moving even when the demo doesn't impress. In real trouble, the pattern inverts: updates get vaguer, questions take longer to answer, and 'almost done' repeats for weeks without the board changing. The trough is normal; silence during it is not.
A checklist you can use
Every build has a hard part, usually at 60-80% done
From outside, the trough looks identical to failure
Healthy sign: communication gets denser, problems arrive with plans
Trouble sign: vaguer updates, 'almost done' on repeat
Agree the bad-news rule before the build starts
When to bring in help
Agree the signal before the build starts: bad news within a day, with a plan attached, no matter what. Then when the hard part comes, you'll know exactly which of the two you're in. If the honest answer is that nobody on the team owns this end to end, that's the moment to borrow the depth rather than improvise it.
Takeaway
Founders who know the shape of a normal build hold steady through the dip, and holding steady through the dip is precisely when the compounding you paid for happens.
Building this? Devxhub → devxhub.com
Top comments (0)