The "Almost Done" Developer Is the Most Dangerous Hire

There's a developer archetype that will cost you more than any bad hire you've ever made. Not the one who tries and fails. Not the one who submits garbage code that breaks on day one. Those people are easy. You catch the problem fast, you move on, you're out a few weeks.

The one who will really hurt you stays. He shows up to every standup. He always has a status update. He's engaged, he seems to care, he talks confidently about the work. And every single time you ask him where things stand, you get some version of the same answer.

Almost done.

I've spent north of $300,000 on software development over the years that went absolutely nowhere. Some of that money was just the tuition for learning what bad hiring looks like at scale. And the "almost done" developer is the most expensive lesson in that curriculum - not because of the direct invoice, but because of what they leave behind when they go.

I just watched this play out again, in real time, on my own product. A developer we hired for a clearly scoped build strung us along for months. When it was finally over, we had fake code where real features should have been, an invoice for work that had been paid, and a codebase that the next developer had to treat like a minefield.

I'm going to walk you through exactly what happened - what the code looked like, what the invoice said, and what you can do to catch this pattern before it drains you.

The Build and the Pattern

We were building an embeddable AI chatbot for Galadon - the kind you drop onto any website with a script tag. Clean requirements. Three specific features: streaming responses so the AI output appears word by word as it generates, a Slack integration so conversations surface in a workspace channel, and a Zapier integration for automation. Clearly scoped. Not ambiguous.

We hired a developer. Smart guy. Confident in calls. Understood the requirements, asked reasonable questions, seemed to know exactly what he was doing.

Week after week, check-in after check-in, the update was the same. Almost done. Almost done. Almost done. One of my team members put it better than I could: that was this guy's catchphrase. Every single time, in every single meeting, always almost done. And it was never done.

Now, I run a fast-moving team. I trust people to flag problems early so we can adjust. But when someone keeps telling you they're almost done, there's a natural human tendency to believe it. Because what's the alternative - that they've been lying to you for months?

Turns out, that's exactly what was happening.

What "Almost Done" Looked Like

Let me get specific, because the details are what make this useful.

Feature one: streaming. Streaming means the AI response appears word by word in real time, instead of waiting for the whole answer to generate before displaying anything. You've seen it on ChatGPT. The technical implementation uses Server-Sent Events - the server pushes data to the browser continuously as the model produces it. It's a well-documented pattern. Not exotic work.

What our developer delivered was not that.

What he built was a function that calls the chat API in a loop - every second, make the request, get the data, make the request, get the data. It looks like streaming on the surface if you don't know what you're staring at. But it's polling, not streaming. The difference isn't cosmetic. Polling hammers your server, creates latency, and fails under load in ways real streaming doesn't. My developer looked at the code and laid it out plainly: "This is calling the API again and again and getting the data. This is not streaming."

Had we not caught it, that fake streaming code would have gone into production. It would have created performance problems, confused every developer who came after, and eventually broken under any real usage. And this contractor was billing for streaming.

Feature two: Slack integration. The requirement was simple - when a user chats with the bot, the conversation shows up in a designated channel. What got delivered was a shell. It was piping messages from every chatbot in the system into the workspace, completely unscoped. Basic filtering that was obviously part of the spec wasn't there. It was wired up in a way that looked functional from the outside but wasn't - a half-built thing that would take more work to remove cleanly than to build correctly from scratch.

Feature three: Zapier. When we went to verify the integration, we couldn't even confirm it was running on our account. We had to dig into credentials to figure out whether the implementation was in our Zapier workspace or his personal one. That's not an "almost done" integration. That's a feature that was never completed and never properly configured for handover.

Three features. Zero were done.

And Then Came the Invoice

Here's where it gets instructive.

After this developer was gone - after my team was already in the code, trying to figure out what was salvageable - we got an invoice. He wanted to be paid for the work.

The full picture: he had already been paid. Around $2,500 for the original scope. When he left, he told us everything was complete. Everything was done. He'd fulfilled the contract.

None of it was done.

So now we're going line by line through this new invoice. Streaming - which was fake and was already in the original paid scope anyway. Slack integration - a shell that doesn't meet basic requirements. Zapier - couldn't verify it was even ours. He was billing us for all of it.

My team's read on it was pretty clear: he didn't deliver one thing that worked. He wasted months of time. He didn't do a proper handover - no documentation, no architectural explanation, nothing. Just gone, with broken code left behind like landmines for whoever came next.

There's an uncomfortable ethical question that comes up in these situations: if some of his code is technically in the product, even barely functional, do you owe him anything? My answer is you owe him proportionally to what he delivered - not what he claimed. And if he was already paid for work he never completed, the math doesn't favor paying again.

Why Founders Keep Falling for This

I want to be honest. This wasn't my first time dealing with the "almost done" developer. Even with everything I've been through, I still find myself in these situations occasionally. So let me break down exactly why this pattern is so effective at extracting money from people who should know better.

Technical asymmetry. Most founders can't read code and evaluate it in real time. I can't. I know what good output looks like - a feature that works, responds correctly, handles edge cases. But I can't look at a diff and tell you whether the implementation is solid or a disaster waiting to happen. So when a developer says "streaming is almost done," I have no immediate way to verify it. I have to trust. And "almost done" is calibrated to sound trustworthy.

Sunk cost is a trap. By month two, you've paid this person real money. You've invested in onboarding them, explaining the product, walking through requirements on multiple calls. If you accept that nothing has been delivered, you're accepting that all of that was wasted. That's a hard thing to sit with. So you keep believing in "almost done" because the alternative means admitting the loss. And every week you wait, the sunk cost climbs.

Confidence gets mistaken for competence. The "almost done" developer is usually very confident in meetings. They use the right vocabulary. They engage with problems. They seem to understand what you need. That confidence reads as competence, especially when you're not in a position to technically verify their work. The fake streaming code my developer submitted wasn't random - it did something. It was built by someone who understood the goal but didn't know how to achieve it correctly, and was too proud or too scared to say so.

The phrase itself delays accountability. "Almost done" doesn't invite follow-up. It doesn't say "here's what's blocking me" or "I need guidance on this specific part." It says: I'm handling it, check back later. Every check-in resets the clock. You get a small hit of relief - progress is being made - and the developer buys another week. Multiply that across three months and you've burned a quarter of the year on nothing.

The Cost Beyond the Invoice

The $2,500 we paid for work that wasn't delivered is annoying. But it's not the real damage.

The real damage is what happens after they leave.

When a developer exits without documentation - without explaining what was built, why it was structured that way, where the edge cases live - they leave a tax on everyone who follows them. My current developer spent serious time just trying to understand what was in the codebase before he could start building. Time that should have been spent moving the product forward was spent doing archaeology on what the previous guy had claimed was done.

That tax compounds. Every hour of confusion, every bug traced back to undocumented architecture, every integration that has to be rebuilt because the original was fake - that's all interest on the initial bad hire. And unlike a direct payment, it's invisible. It doesn't show up on an invoice. It just eats your roadmap.

I've burned through over $300,000 in software development over the years that didn't produce anything lasting. Some of those projects I've talked about in detail. The pattern is always the same: someone who communicates well, seems confident, is always making progress - right up until you realize nothing is done. And by then the money is spent and you're starting from scratch.

The "almost done" developer doesn't just waste what you pay them directly. They waste the months you could have spent with someone who would have told you in week two that the requirement was unclear, or that they weren't equipped for one specific piece, and let you course-correct fast. Fast honest failure beats slow fake progress every time.

How to Catch It Early

There's no foolproof system here - I've made this mistake more than once and I'll probably make a version of it again. But there are concrete changes I've made in how I hire and manage developers that would have caught this situation weeks earlier.

Tie payment to working demos, not milestones. A milestone is a promise. A working demo is proof. "Slack integration complete" is a milestone. "Here is the chatbot running on this test URL, I've connected it to this channel, here are three live messages I just sent through it" - that's a demo. Never release payment for a milestone. Only pay for what you can test yourself, end-to-end, right now. If they can't show you a working demo, the feature isn't done.

Ask them to explain the implementation out loud. You don't need to understand code to spot whether someone knows what they built. Ask: "Walk me through how the streaming works. What happens on the server side when a user sends a message?" A developer who built it correctly can explain it in plain language. A developer who faked it will hedge, go vague, use jargon without substance, or pivot to showing you the output rather than explaining the mechanics. The fake streaming code I described - if we'd asked "how does data flow from the server to the browser in real time?" - we would have caught it on the first demo call.

Get a second set of eyes on the code before final payment. You don't need a full audit. Hire a freelancer for two hours to do a spot check on the critical features. Give them the spec, point them at the relevant files, ask them to tell you if the implementation matches. That review would have caught the polling-as-streaming issue immediately. The cost is trivial compared to months of bad build time.

Require a handover document as a contract term from day one. Before any work starts, the contract should specify: at completion, the developer delivers documentation covering architecture, third-party accounts and credentials set up in your name, known issues, and a recorded walkthrough. If they push back on this upfront, that tells you something. If they agree and then don't deliver it - that's a breach and you hold payment accordingly. No handover, no final payment. Non-negotiable.

Do the price test before you commit. When I was building Galadon, I quoted the same feature set to over a dozen developers. The spread was wild - $1,500 on one end, $20,000 on the other, for identical requirements. That range alone tells you something is off with how most people price development work. Run the quotes. Ask each person to justify their number with a specific breakdown of what they'll build and how long each piece takes. The developer who gives you a granular estimate with clear reasoning is worth far more than the one who gives you a confident round number. The exercise also filters out people who don't really understand the scope - which is often exactly who you want to avoid.

Treat "almost done" as a flag, not a status update. The moment a developer uses that phrase more than twice in a row without a specific list of what remains and a concrete date - ask them to write down exactly what's left. Not to micromanage, but because forcing specificity either produces real clarity or exposes that they don't have any. Genuine progress can always be described precisely. Fake progress hides behind vague language.

The Harder Lesson

There's a version of this story where you get burned, get more careful, and move on. That's useful, but it's not the full picture.

The real lesson is about what progress means when you're building something technical. Progress isn't check-ins. It isn't confidence in meetings. It isn't someone showing up consistently and seeming engaged. Progress is working software that does what it's supposed to do - that you can test right now, that your team can verify, that the next developer could pick up without spending weeks reverse-engineering undocumented decisions.

The developer who tells you in week one "I'm not sure I can build the streaming the way you described, here's what I can do instead and here's why" is worth ten of the one who nods along and delivers a polling loop with streaming comments pasted on top.

Honest bad news early is a gift. Almost done" is a debt you keep accumulating until the whole thing collapses.

If you're in the middle of a build right now and you've heard "almost done" more times than you can count - don't wait for the invoice to find out what's been built. Demand a working demo. Ask for the implementation explanation. Get a second opinion on the code. The longer you wait, the more expensive the conversation gets.

And if you want to talk through how you're structuring developer relationships, scoping features, or building out technical products without getting taken - that's exactly the kind of thing we dig into in Galadon Gold. Real situations, not theory. Come build with people who've already made the expensive mistakes.