Building trust after a failed project
A client calls you in after investing six months and a lot of money into a software project. Almost nothing was delivered. The previous team is gone, the client is furious, and they have no reason to trust the next engineer who walks through the door.
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 damaged relationship matters more than 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. Rebuilding that relationship comes before repairing the software.
Rhythm over results
What works is rhythm, a predictable cadence where the client sees something happen every week. I keep the meetings short and show what is there before asking what should happen next. We finish by confirming the decisions. The schedule itself carries the message: you will hear from me again next 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 and architecture, then use the domain model to check whether I actually understand the client’s business. Nobody has ever complained about an engineer who turns up having done that homework.
Small promises
I keep the first promises deliberately small. If I say the login flow and dashboard skeleton will be there next week, I make sure that is what I can show. After three or four weeks, the client spends less time checking whether I will disappear and starts talking about what should come next. They have watched me make a promise and keep it several weeks in a row.
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 listening, because the client needs to see their input affect what gets built. A suggestion may appear in the next delivery, or I may explain why we cut it; either way, they can follow the decision instead of wondering whether I ignored them.
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. I helped build out their platform and hire their development team, and I now sit in on management meetings.
It started with a weekly meeting and a promise I could keep. I listened, wrote down the decisions, and came back the following week with what I said I would deliver.
