Why "Almost Done" Is the Most Dangerous Phrase in a Startup

The Phrase I've Learned to Treat Like a Red Flag

I was on a product call with two engineers. We were building a chatbot feature for one of my platforms - a tool that lets users configure and embed AI chatbots, capture leads, handle notifications, control appearance settings.

About ten minutes in, one of the engineers mentioned the Slack integration. He'd been working on it. Authentication was giving him trouble, but he was close. Almost done.

I noted it and moved on.

Twenty minutes later, same engineer, same report: Slack integration is almost done. Just needs a little more time.

Twice in one call. The phrase I've learned to treat like a warning signal: "almost done."

Both times I redirected. The API wasn't done. The root domain hadn't been changed, and the SSL certificate wasn't configured. We were missing core endpoints: chatbot initialization, chatbot deletion, appearance settings, lead collection. The file storage wasn't set up correctly. We had a half-built foundation and a decoration that was 80% ready to hang on a wall we hadn't finished building.

Finishing the Slack integration in that state would have cost us rework, delay, and the momentum loss that comes from shipping things in the wrong order.

That's the "almost done" trap. And once you recognize it, you'll see it everywhere - in product development, in agency work, in cold email campaigns, in the way teams allocate attention toward the things that feel close instead of the things that need doing.

Why 80% Complete Feels Like Urgency

When something is incomplete, your brain keeps flagging it. But when something is almost complete - when you can see the finish line - that pull gets stronger. The sunk cost of the work already invested creates gravity toward completion. Stopping at 80% feels like throwing away 80% of the effort.

So instead of asking "should I finish this?" you ask "how do I finish this faster?" Proximity to completion replaces the question of whether completion is even the right move.

Teams end up shipping features that miss the mark, finishing sequences built on broken offers, or spending a week polishing a prospect list that targets the wrong companies. The question of whether to finish never came up - because it was almost done, and almost done feels urgent.

The key insight: completion percentage and priority are completely different things. A thing that's 80% complete isn't 80% of the way to being useful. It might be 80% of the way to being finished but 0% of the way to being functional - because the thing it depends on isn't built yet.

What Was Blocking Us

On that call, once I redirected away from Slack integration, we mapped out what was standing between us and a working product. The list was longer than expected.

First: the root domain. We needed to move to a consistent domain structure. Sounds minor. It wasn't. Every downstream configuration depended on it - the SSL certificate, the Nginx setup, the API endpoint structure, the file storage bucket naming. If we kept building on the wrong domain, every future change would require a rework. This had to be resolved before anything else could be touched.

Second: the API endpoints. Chatbot initialization and deletion. Appearance settings covered profile picture, theme color, initial message, and suggested messages. Lead collection, plus notification email setup. These are the things that make a product work for someone paying for it.

Third: everything else. Slack and Zapier integrations, and the integrations page in the UI. The solution for these was simple: hide the page. Don't ship it broken. Come back when the foundation is solid and the core product works. I said this explicitly on the call - hide the integration page, come back to it later. It was parked until the foundation was solid.

Once we laid it out that way, the priority became obvious. Domain change and API endpoints finished that day. Integrate with the front end the following day. Present it after that.

The question that cuts through "almost done" every time is: does completing this thing unlock the next step, or does it need something else before it can function?

Finishing Slack integration unlocked nothing while the API was incomplete. Finishing the API unlocked everything. So we did the API.

The Cold Email Version of This Trap

Different context, identical trap.

A client comes in with a cold email sequence they've been working on for three weeks. Five emails. Subject line variations. They'd run a P.S. test on the final email. Almost done - can we review it?

I ask: what's the offer?

Pause.

The offer is something like "marketing consulting and lead generation for agencies." Or "strategic advisory for growth-stage B2B companies." Something that sounds like it means something but means nothing to the person reading it at 8am who's already deleted forty-seven other emails that morning.

Three weeks of work. Almost done. Built on a foundation that doesn't exist.

I had this exact situation recently with a Galadon Gold member. Came in wanting to offer marketing consulting and lead gen to agencies. A younger version of me might have just reviewed the sequence. But it fails too often. So I asked two questions: what's your background, and what's the biggest ROI result you've ever delivered?

Turns out he'd spent ten years in fintech. And his biggest result? He took a company from zero leads at a trade show to 150 leads in three days - same booth, same spend, completely different execution.

That's the offer - the specific thing that happened, with a number attached. Once we had that, building the cold email sequence took a couple of hours.

If I'd let him stay focused on his almost-done sequence, we'd have launched it, gotten terrible reply rates, diagnosed it as a targeting problem, rebuilt the prospect list, tried again. Weeks gone. The sequence was almost done. The offer was zero percent done. And "almost done" had captured all the attention.

If you want to nail the offer before you write a single word of outreach, the Discovery Call Framework forces you to articulate the specific result you deliver - before you touch any copy.

The Prospect List Version

There's another version of this that hits specifically in list building. You've spent a few days scraping, enriching, validating. You're 80% through. Almost done. That near-completion makes you want to push through and finish rather than stopping to ask: is this even the right list?

Are these companies in the right size range? Do they have the problem your offer solves? Check whether you're reaching the decision maker who can write the check, or only the person who forwards your email up the chain.

The list-building process takes days. The questioning process takes twenty minutes. But once you're 80% through the list, the questioning doesn't happen - because finishing feels more urgent than questioning.

This is one reason building lists fast pays off beyond efficiency. When a list takes two days to build manually, you're emotionally attached before you've validated the targeting. When it takes twenty minutes - using something like the ScraperCity B2B database - you haven't sunk much. You're far more willing to question it, adjust the filters, rebuild it if the targeting turns out to be wrong.

Low attachment to the list means you'll ask whether it's the right list before you send to it. High attachment - which near-completion creates - means you skip the question and just send.

How to Audit Your "Almost Done" Stack

A pile of things at 70%, 80%, 90% complete that have been sitting there for weeks. The work already invested makes them hard to cut. So they stay on the roadmap, occupying mental space, generating guilt, and pulling attention away from what needs to happen.

Is it a dependency or a decoration? A dependency is something other things need in order to function. The API was a dependency in our case - nothing downstream worked without it. A decoration adds value once the core is solid: Slack integration, Zapier, the P.S. on your email sequence. Decorations matter, but not before the foundation is in place. If your almost-done item is a decoration, don't treat it like a dependency. Sequence it correctly.

What does finishing this unlock? If completing this thing enables the next step, do it. If it doesn't enable anything - because something it depends on isn't done - stop and do the dependency first. Completion percentage has nothing to do with sequencing. The question is whether finishing this moves the critical path forward.

Would you start this today if it were 0% complete? This is the sunk cost question. Forget the work already done. If you were starting from scratch right now, with everything you know today, would this even be on the roadmap? If yes, sequence it properly. If no, cut it. Finishing something you wouldn't start today means shipping features that don't matter.

Hide it. This is the most practical move. Sometimes the right call with an almost-done feature is to remove it from the UI, park the code, and come back when the foundation is solid. We did this explicitly on the call - hide the integration page. Hiding it was the right call. Shipping something broken because it's almost done is worse than shipping something without it at all.

Almost Done on the Wrong Thing Is Still the Wrong Thing

I think about this in the context of a business decision I had to make not long ago. Someone gave me advice that sounded smart on the surface: I could 10x my affiliate revenue if I just emailed my list every day pitching affiliate products. The strategy was almost completely thought through. Looked like a fast win.

But what it would have done is pull energy away from SaaS - where value compounds. $10K a month in affiliate revenue is worth $10K. $10K a month in SaaS revenue is worth $360K or more in enterprise value when you go to sell. The advice was almost right. And "almost done" thinking about the affiliate strategy would have made it feel more urgent than it was.

Same dynamic. The decoration - affiliate income - looked shiny and close. The dependency - building a SaaS business with enterprise value - was harder and further away. "Almost done" pulls you toward the shiny thing every time if you're not paying attention.

Ask which thing, once complete, builds something that compounds over time.

The Question That Cuts Through It

At the end of that product call, we had a clear plan. Finish the API today, integrate with the front end the next day, then present. Slack integration: parked. Zapier: same. Both were still on the roadmap, just not next.

The engineer who mentioned Slack integration twice wasn't wrong for wanting to finish it. Slack integration should ship. But "almost done" had manufactured urgency the feature hadn't earned - because the thing it needed to function wasn't complete yet.

"What needs to happen next?" cuts through it every time.

Ask what completing this makes possible that wasn't possible before. If the answer is "nothing, until X is done" - you're looking at a decoration. Hide it, park it, sequence it correctly. Do X first.

The most dangerous moment in any project is when you're 80% through the wrong thing. 80% complete feels so close to done that you stop questioning whether you should be doing it at all.

Always question it. Especially when it's almost done.

If you're running cold email right now and want to get the order of operations right - offer first, targeting second, copy third - the Best Lead Strategy Guide walks through exactly that. And if you want to work through prioritization with people who've made these mistakes and fixed them, Galadon Gold is where that conversation happens live.