Every developer has at least one project they'd rather forget. The one where something went wrong — sometimes badly wrong — and they had to figure out how to recover it, or accept that recovery wasn't fully possible.

I have a few. I'm going to tell you about one, because I think the details are more useful than a generic post about "how to have a successful project."

What happened

A few years ago I took on a project that was larger than I'd scoped it. The client had a solid business, a clear idea of what they wanted, and a launch date tied to a trade show — the kind of hard deadline you can't move because three thousand people have it on their calendars.

The scope was ambitious. Custom e-commerce with specific business logic around wholesale pricing, a client portal for existing accounts, and a product catalog with a complex filtering system. I'd done each of those things before, but not all at once for a launch in twelve weeks.

I said yes. I was confident I could do it.

Around week seven, I hit a problem with the wholesale pricing system that was more complex than I'd anticipated. The client's pricing rules had exceptions and edge cases that weren't captured in the original requirements — not because they hid them, but because nobody had asked the right questions. The rules were in the client's head, not in any document.

I was behind. Not catastrophically, but enough that I had to have a difficult conversation.

The conversation I had to have

I told the client exactly what was going on. Not a softened version of it — the actual situation: I had underestimated this part of the project, we had found complexity that wasn't in the original scope, and I had two options to offer.

Option one: reduce scope for launch. Ship the core e-commerce without the wholesale portal, launch on time, and add the wholesale system in the weeks after as a phase two.

Option two: push the launch by three weeks and deliver everything as originally planned.

The client needed to make a business decision, and they couldn't make it without accurate information. Keeping them comfortable with optimistic updates until the deadline hit and I couldn't deliver would have been far worse than this conversation.

They chose option one. We launched on time with a slightly reduced scope, the show went well, and we shipped the wholesale portal a month later.

What I changed

The experience made me much more rigorous about a few things.

Requirements gathering before commitment. I now ask a lot more questions about edge cases before scoping anything. "Tell me about your pricing exceptions" and "walk me through the weird cases" before I write a proposal, not after I'm three weeks into the build.

Milestones with check-in points. I structure projects with formal milestone reviews now — not just "I'll let you know when it's done" but defined points where we assess progress against timeline and scope. Problems that surface at week three are much cheaper than problems that surface at week ten.

Scope buffers for complexity. I build in time for the unexpected. Not as padding — as an honest acknowledgment that requirements evolve and complexity is real. If the project comes in under budget because we didn't need the buffer, that's a conversation I'm happy to have.

Difficult conversations early. This was the most important thing. The instinct when a project is behind is to work longer hours and hope you can make it up before anyone notices. That works sometimes. When it doesn't, you've traded a manageable problem for a crisis. I'd rather have a hard conversation at week seven than an impossible one at week twelve.

What clients should take from this

Projects go wrong. Not always dramatically, but the ones where nothing unexpected happens are in the minority. What matters is how the developer handles it when things get complicated.

Ask your developer about a project that didn't go as planned. Not to judge them — everyone has one — but to hear how they handled it. Did they communicate early? Did they give you options? Did they own the problem or deflect it?

The way someone handles adversity is often more telling than the way they handle smooth sailing.

If you want to work with someone who'll give you the real picture, even when it's uncomfortable, get in touch. That's the kind of engagement I can offer.