Building trust after a failed project

A client calls you in. They invested six months and a lot of money into a software project, were promised a lot, and got almost nothing. The previous team is gone and the client is furious.

You show up, and they don’t trust you either. Why would they? You’re just another engineer making promises.

This has happened to me more than once, and my instinct is always the same: jump in, start building, show them I’m different by proving it with code. But code doesn’t fix a broken relationship, and that’s the actual problem I need to solve first.

The real problem

When a project fails like this, the real damage is to the relationship, not the codebase. The client feels stupid for trusting the last team, feels lied to, and has lost confidence in their own ability to judge whether things are going well. So when you show up and say “I’ll have something for you in two weeks,” all they hear is the same thing the last team said. You need to fix the relationship before you fix the software.

Rhythm over results

What actually works is establishing a rhythm, a short and predictable cadence that gives the client control and visibility. For me this means weekly sessions, not biweekly sprints. Short meetings where I show what’s there, ask what matters most next week, and confirm decisions. The cadence itself is the message: you will hear from me, reliably, every single week.

Writing decisions down is part of this, because decisions that aren’t recorded don’t exist. When a client has been burned they need proof that they were heard, even if it’s just a bullet list in an email after the meeting. This single habit does more for trust than any technical demo, because it shows you actually listened and acted on what they said.

The first couple of weeks I usually don’t have much working software to show, and that’s fine. I show the plan instead, the architecture, the domain model. Nobody has ever complained about an engineer who shows up with a clear understanding of their business. The point is to demonstrate that I know where I’m going, not to impress them with output.

Small promises

The fastest way to rebuild trust is to promise small things and deliver them, rather than promising big things and hoping you’ll make it. If you say “next week I’ll have the login flow and the dashboard skeleton” and then you deliver exactly that, something shifts. You did what you said. Do this three or four times in a row and the dynamic changes completely; the client stops worrying about whether you’ll disappear and starts thinking about features instead. Consistent small deliveries compound into confidence faster than any big reveal ever could.

This also has a useful side effect: it forces me to scope tightly, because I can’t promise a small deliverable if I haven’t thought carefully about what’s actually achievable in a week. It turns out that “what can I realistically finish by Thursday” is a better planning question than most frameworks will give you. That discipline helps the project as much as it helps the relationship.

Why I spend most of my time listening

In these situations I spend a disproportionate amount of time just listening, not because I don’t know what to build, but because the client needs to feel that their input actually changes what gets built. Whether their suggestion shows up next week or gets cut with an explanation, either outcome tells them the process is honest, and both build trust.

Listening also helps me avoid the trap of just building the same thing faster. Often the original scope was wrong to begin with, and the client has learned things during those six months of failure that they didn’t know at the start. If I jump straight into building what the last team was building, I’m repeating the mistake with better execution. Taking the time to listen gives me the chance to actually solve the right problem.

It works

The project I’m thinking of is now in its sixth year. We went from weekly damage control to building out their entire platform, hiring their development team, and sitting in on management meetings.

But it started with showing up every week, writing things down, and delivering what I promised. Nothing fancy. Just rhythm.