Lessons from Projects That Went Sideways

I have a folder on my computer called "post-mortems." It's where I keep notes on projects that didn't go the way I wanted. Not disasters exactly. No lawsuits, no complete failures. But engagements where something went wrong, where I could have done better, where I lost sleep.

I don't share this stuff publicly often. It's not great marketing to admit your mistakes. But I think there's value in honesty about the messy reality of doing this work. Everything else you read makes it sound like success is inevitable if you just follow the right framework. That's not been my experience.

Here's what I've learned from the ones that went sideways.

The redesign that nobody wanted

A few years ago, I took on a redesign for a mid-sized e-commerce company. Their site was dated. It probably hadn't been meaningfully updated since 2015. The new CMO wanted something fresh, modern, that reflected where the brand was going.

I did good work. Genuinely. The design was sharp, the code was clean, the performance was excellent. We launched to... crickets. Sales didn't improve. Some metrics actually got worse. The team was confused, I was confused.

What I eventually figured out: the customers didn't care about the redesign. The existing site was familiar to them. They knew where everything was. The new navigation, while more logical, broke their muscle memory. The new visual style, while more contemporary, made the brand feel less trustworthy to their older demographic.

We'd solved a problem that existed in the CMO's head, not in the market. The site was embarrassing to show at industry conferences, but it was working fine for actual customers.

What I learned: Always ask who the redesign is for. "It looks dated" is not a business problem. "Our conversion rate is below industry benchmarks" or "customers can't find products" are business problems. Sometimes the best answer is "your site is ugly but working, don't fix it."

The scope creep I didn't stop

I have a habit of being too accommodating. A client asks "could we also..." and I say "sure, that's not a big deal." Sometimes it isn't. But those small additions compound.

The project I'm thinking of started as a marketing website and ended as something approaching a full application. The client kept having ideas (good ideas, honestly) and I kept saying yes. We'll just add this feature. We'll just integrate with this system. We'll just build this little tool.

By month four, I was working at an effective hourly rate that made me angry every time I calculated it. I couldn't increase the budget because I'd agreed to all the additions. I couldn't deliver less because I'd committed. I was trapped in a project I'd built the walls of myself.

What I learned: Scope changes need a process. Now I have a simple rule: anything beyond the original spec gets a mini-proposal. Takes me 10 minutes to write, gives the client a clear picture of time and cost, creates a decision point. Most of the time they say yes. Sometimes they say "actually, that's not worth it." Either way, we're aligned.

The client who wasn't ready

I've gotten better at spotting this, but not perfect. This was a startup, well-funded with smart founders and a genuinely interesting product. They wanted to build their main platform, and the technical challenges were right up my alley.

Three weeks in, the specs changed. Not a little. Fundamentally. The core user flow was different. The data model was different. Okay, I thought, startups pivot. We adapted.

Three weeks later, it changed again. And again. The founders were still figuring out their product in real-time, using the development process as their R&D. Every time they talked to a potential customer, the requirements shifted.

I eventually had a hard conversation: we need to pause active development until you have more clarity. They weren't happy about it. They wanted to "move fast and iterate." But what we were actually doing was burning money on code that would never ship.

What I learned: There's a minimum level of product clarity needed before engineering makes sense. If you can't describe the happy path for your primary user, you don't need a developer. You need more customer conversations, more prototyping, more thinking. That's okay. That's where startups should spend time. But I can't help with that part.

The one where I was wrong about the tech

This one still stings a bit. A client had an existing system built on a stack I considered outdated. I recommended rebuilding on something more modern. Better tooling, better ecosystem, easier to hire for, all the sensible arguments.

We rebuilt. It took longer than expected. The migration was painful. And here's the thing: the new system wasn't meaningfully better for their use case. The old tech was "outdated" but it was stable, the team knew it, and it did what they needed. The new system did the same things, just in newer technologies.

I'd let my preferences override their needs. The "better" stack wasn't better for them; it was better in abstract. I'd recommended a rebuild based on what I wanted to work with, rationalized as being "for their benefit."

What I learned: Be honest about why you're recommending something. "This tech is exciting and I want to use it" is a valid input, but it's not a client benefit. Sometimes the right answer is "your old tech is fine, let's just clean it up."

The communication breakdown

I'm not naturally a frequent communicator. My instinct is to go heads-down on a problem, solve it, and emerge with a finished product. For some clients, that's fine. For others, it's a disaster.

One client in particular. I didn't hear from them for two weeks, so I assumed everything was fine and kept building. Turns out they were deeply anxious the whole time, wondering what I was doing, whether we were on track, whether I'd vanished. When I resurfaced with a progress update, there was a palpable relief that I hadn't realized was needed.

We talked it out. They needed more frequent touchpoints, not detailed reports, just "hey, here's what I worked on today, here's what's next." Five minutes of writing for me, major anxiety reduction for them.

What I learned: Ask how people want to be communicated with. Some clients want a detailed weekly report. Some want a quick daily check-in. Some want to be left alone until there's something to review. None of these preferences are wrong, but I need to know which one I'm dealing with.

The pattern underneath

Looking at these examples, there's a common thread: I could have avoided most of these problems with better upfront conversations. More probing questions early. More willingness to say "I don't think this is the right approach." More calibration on communication style and decision-making process.

The work itself, the actual building, is rarely where things go wrong. It's everything around the work. The expectations, the alignment, the communication, the scope.

I've gotten better at this over the years, but I don't think I'll ever be perfect. The best I can do is learn from each one and try not to make the same mistake twice.

Building something and want to avoid these patterns? [Let's talk](/contact).