Almost Working Is the Most Dangerous Status

We were a few months into building a Slack-integrated AI chatbot. On a recent coaching call, the dev team walked me through the latest build. And I'll be honest - it sounded like good news at first.

Message propagation? Working. GPT cutoff logic? Working. Sequencing - capturing name, then email, then phone number in the right order? Working. Random user ID generation? Figured out. The domain migration was close. The OAuth was queued up. The toggle API was nearly done.

Nearly. Almost. Close.

And then, almost as an aside, the dev mentioned: the app is spamming every Slack user with the same repeated messages in an infinite loop.

Full stop.

That's not "almost done." That's broken. That's unusable. That's unshippable. And if I hadn't pushed - if I'd just heard the list of things that were working and felt the warmth of that progress report - we would have kept cruising toward a launch that wasn't a launch. We would have kept funding the illusion of proximity to done.

This is what I call the "Almost Working" trap. And it is the most dangerous status a software project can have.

Why "Almost Working" Is More Dangerous Than "Broken"

When something is clearly broken, you know what to do. You fix it. You escalate. You bring in someone who can solve it. There is no ambiguity. The red light is red.

"Almost working" is different. It borrows the language of progress to describe a state of failure. It wraps one catastrophic flaw inside a warm blanket of partial victories. The dev shows you the screen. You see messages propagating from Slack to the bot. You see the sequencing work. You see the user IDs being generated cleanly. It looks like a product. It sounds like a product is nearly ready. And so, as a non-technical founder, you nod along, feel cautiously optimistic, and say "great, let's talk tomorrow."

That's exactly what happened on this call. The team had been chipping away at this thing for months. Every check-in produced a new list of things that were working - and a slightly different list of things that were still pending. Slack toggle API. Domain migration. OAuth. Internal API integration. The items rotated. The goalposts moved. The timeline kept slipping from "Monday" to "tomorrow" to "a couple more days."

And the really insidious part? Every single update sounded reasonable in isolation. "It's just a race condition bug." (A race condition, for the non-technical folks, is when two processes try to access the same resource at the same time and get stuck fighting each other - the kind of bug that's genuinely tricky to pin down.) "The desired functionality is actually working, it just floods the Slack channel with repeated messages." "It should be done by tomorrow."

Each sentence, on its own, sounds like a competent developer managing a manageable problem. String them together across six weeks and you've got a founder funding a project that isn't actually moving.

The Math That Founders Get Wrong

Here's the mental model error at the center of this trap: founders think about software completion in percentages. "We're 80% done." So naturally, it feels like 80% of a product has been delivered. The work is mostly behind you. You're in the home stretch.

That's wrong.

A product that is 80% functional and 20% catastrophically broken is not 80% done. It is 100% unshippable. You cannot give a customer a tool that floods their Slack with infinite repeated messages and call it a beta. You cannot demo it to an investor. You cannot charge for it. The 80% that works is irrelevant until the 20% that doesn't is fixed.

This isn't unique to software. If I hand you a car that starts, steers, accelerates, plays music, and has working AC - but the brakes don't work - you are not 90% of the way to having a car. You have an expensive, dangerous object that will kill you the first time you need to stop. The percentage of features that work is the wrong metric. The only metric that matters is: can a real person use this for its intended purpose without it breaking?

If the answer is no, you're not almost done. You're not done at all.

What "Almost Working" Really Means

I've been in enough dev calls to know how this reads from the other side of the table. The developers on this call weren't lying. They weren't sandbagging. They were telling me what was true - a lot of the system genuinely did work. The sequencing was solid. The message routing was there. The user ID logic was clean.

The problem is that technical people think in components. A developer sees ten components, eight of which are functioning correctly, and they report an 80% build. That's accurate from an engineering perspective. But founders and clients don't use components. They use products. And a product is all-or-nothing: it either works end-to-end, or it doesn't work at all.

So when a dev says "almost working," what they actually mean - whether they realize it or not - is: "the parts I understand are done, and at least one part I don't fully understand yet is still broken."

And that last broken part is almost always harder than everything that came before. That's why it's last.

The Timeline Tells You Everything

Here's how I knew this project was in trouble before anyone said anything technical. On Monday, the goal was to have something ready to demo. By the call - which was effectively Friday - we still didn't have a demoable product. When I asked how much progress had been made since Monday, the answer started with "yes, we actually have done a lot" followed by a screen share of Postman and a browser tab showing messages looping.

That's the other signal founders miss: when the timeline keeps compressing into "tomorrow." It's never tomorrow. Once a project has said "tomorrow" twice in the same week, you need to have a different conversation. Not about what's almost done. About what is actually done, what specifically is still broken, what the root cause is, and - most importantly - whether the people working on it have a real fix or just a workaround in mind.

I specifically pushed on that on the call. I said I didn't want a workaround. I wanted functional code. A workaround is just a different kind of "almost working." It papers over the cracks without fixing them, and you'll pay for it later - usually at the worst possible time, like during a demo or right after you've told a customer they can start using it.

How to Have the Right Conversation

If you're a founder managing a dev team - internal or external - here's how to stop funding the "almost working" illusion and start getting real answers.

1. Define "done" before you start

The reason "almost working" has so much power is that there's no agreed-upon definition of done. The dev thinks done means the core logic functions. You think done means a user can complete a full workflow without the app imploding. Get specific. Write it down. "Done means a new user can connect their Slack account, go through the bot's intake flow, and have their name, email, and phone number captured correctly without any repeated messages, errors, or crashes." That's done. Everything else is still in progress.

2. Ask for an end-to-end walkthrough, not a feature list

On every status call, don't let the dev walk you through what's working. Ask them to show you the full user journey from start to finish. New account creation. Full intake flow. Data capture. Whatever the product is supposed to do - watch them do all of it live. If they can't, that's your answer. The parts they can't show you are the parts that aren't done.

3. Distinguish between bugs and unknowns

A race condition bug that floods Slack with infinite messages is not the same as a typo in a CSS file. When something is "almost working," you need to understand whether the remaining issue is (a) a known, understood problem with a clear fix that just takes time, or (b) an unknown problem where they haven't figured out the root cause yet. The second category is the dangerous one. If your developer knows exactly why the bug is happening and exactly how to fix it, "tomorrow" might actually mean tomorrow. If they're still diagnosing, tomorrow means nothing.

4. Set a real deadline with a real consequence

I closed the call by agreeing to talk the next day - same time. That's the right move when you've been patient and want to give the team a fair shot. But there has to be a consequence attached to missing another deadline. Not a punitive one, necessarily. But some kind of forcing function. The project has been "almost working" for months. At some point, "almost working" costs you something - whether that's a customer you can't demo to, a revenue month you lost, or a relationship with a partner that erodes because you kept promising and not delivering.

The Founder's Job Is to Demand the Only Status That Matters

I've built and sold five SaaS companies. I've been on both sides of this - as the person writing the progress reports and as the person receiving them. The thing I've learned is that founders who let "almost working" slide aren't bad at tech. They're bad at asking hard questions because they don't want to seem like they don't trust their team, or they don't want to create conflict, or they're secretly hoping the optimistic version of the update is true.

I get it. Optimism is what gets you to start a company in the first place. But optimism applied to a broken product is just denial with a prettier name.

Your job isn't to trust the progress report. Your job is to verify it. Show me the demo. Walk me through the full flow. What exactly is still broken? Do you know why? Do you know how to fix it? When does the fix ship? And if this exact conversation happens again next week, what does that tell us about our process?

Ask those questions every time. No exceptions. Because the only status that moves a product forward isn't "almost working." It's done - or it's broken. Everything in between is just expensive ambiguity.

If you're trying to build out your outbound system while managing product chaos like this, the 7-Figure Agency Blueprint is a solid place to get grounded on what actually scales. And if you want to talk through the specifics of your situation directly - what's working, what's stuck, what you should actually be focused on - that's what Galadon Gold is for.

The call I wrote this post from? We're doing it again tomorrow. And this time, there's going to be a demo - or there's going to be a different kind of conversation.