6 min read
Seven years with one client: what repeats me
The same client has kept hiring me across four different projects, from a Selenium migration to a multi-agent GenAI platform. I wrote down what I think drives that.
In 2018 I started a QA automation rescue for a global industrial company. It was supposed to be a short engagement. Eight years later I’m still contributing, now as the architect of their enterprise GenAI platform.
That has been four projects for one client, and the scope has grown steadily. I’ve been asked often enough what I think drives it that I want to write the answer down.
The usual explanations
I don’t think it’s loyalty, because enterprises are ruthless about vendor decisions. Every project goes through procurement, and hires and renewals are benchmarked against what else is on the market. If a new engineer with a shinier deck can demonstrate equal value at a lower rate, the CTO’s job is to pick them.
I am also not the cheapest person they could hire, and I’m not local. I work from Sarajevo while they’re across the globe, and half the meetings are async.
Nothing in the contracts locks them in either. Every engagement has been a discrete scope of work with a clean exit.
What repeats me
I think it comes down to three things that compound over time.
1. The handoff is clean
When I finish a project, I leave it in a state other people can carry on with. The framework I built on one project in 2019 was picked up by 4+ other teams after I rotated off. The pipeline I wrote on their Azure DevSecOps project is still running and is understood by engineers who’ve never met me. The Bicep IaC on the GenAI platform has comments explaining the why of every non-obvious RBAC grant.
The number of senior engineers who leave behind code that requires them to be on call forever is enormous. Their mistake is that they confuse tribal knowledge with job security. In my experience, clients bring back the engineers who can leave cleanly, because they don’t resent what those engineers left behind.
2. The scope grows, within limits
On the GenAI platform I ship end-to-end: Python agent, .NET orchestrator, React UI, Azure infra, CI/CD. I could keep expanding into writing the marketing site or owning the product roadmap, but I choose not to. There are roles on the team owned by people better at those things than me, and my job is to make them look good.
My rule is to own as much as I can do excellently and refuse anything that would dilute my signal, because clients don’t re-hire generalists who stretched into areas where they were mediocre.
3. I tell them the truth early
If an architecture is wrong, I say it in week one, before I’m sunk enough to be polite. I push back on unreasonable deadlines while I can still renegotiate, and I refer requests outside what I should be touching to someone better.
Clients are used to vendors who say “yes” to stay in the room, so they notice the ones who say “no” to protect the outcome. Enterprise decision-makers know from experience that a slightly disappointing truth in week one is better than a catastrophically disappointing delay in month six.
What this looks like in practice
When they asked if I could architect their GenAI platform, I could have overstated my LlamaIndex experience and sounded confident, and I might have gotten the project.
I said something closer to: “I’ve done production RAG on a smaller scale, I’m strong on the architectural primitives, but this specific framework combination I’d be learning on the job in the first two weeks. If that’s acceptable, let’s do it. If you want someone already deep in LlamaIndex, I can recommend two people.”
They said yes, and the project shipped.
I think admitting the gap counted as a credential. It proved I could be trusted to tell them what I didn’t know, which means they could trust what I said I did know.
Optimizing for the next engagement
Many consultants optimize for the current engagement and try to extract the maximum value from the contract they have now, which only gets them a local maximum. The global maximum comes from optimizing for the next engagement you haven’t pitched yet, so the project you’re on right now becomes a long, paid audition for it.
Once you see it that way, you write better docstrings, decline scope creep and coach the junior who might someday recommend you back. You also start to see your client’s team as a referral network that will either champion you or warn the next hiring manager.
Seven years in, I think of that client as a group of engineers I’ve been trying to leave better than I found them.
If you’re building something where the architect’s long-term fit matters, let’s talk. I like engagements that turn into repeat work.