How We Won Trust and Partnership in a Dual-Vendor Setup

Recently, we successfully finished the Due Diligence process with one of our clients and we’ve started the next, more challenging phase. Phase 2 was focused on improving their code and processes which was really exciting for us. We knew we could bring value and achieve improvements in all areas – from Backend and Frontend, to QA and PM. However, there was a twist. We found ourselves in a dual-vendor setup.

The client already had an existing third-party team, for a couple of years. That team was familiar with client’s legacy code and system. We were of course aware that their not so good code practices and lack of process led to this not so good situation. Suddenly, we were stepping into their territory. For a client, this was a strategic moment: within three and a half months, they had to decide whether to keep both teams, to expand ours and move fully in our direction, or to stick with the existing vendor. For us, this was more than just a regular project. Our patience, adaptability and staying professional were in focus and closely monitored by both internal and external stakeholders.

The Challenge of Coexistence

Let’s be honest. When your team is in a dual-vendor setup, you share the same space, dynamics, and it can get complicated. It’s not just about code. It’s about ownership, trust, and collaboration, or the lack of it.

The existing vendor had the upper hand in one sense: they knew the product’s history inside out. But knowledge can sometimes turn into a gatekeeping tool. When our team started to work on the improvements, we started to notice the resilience. For instance, the team refused to have daily meetings with us. We all know daily meetings are a perfect place to share status, resolve blockers and get the update quickly. However, with this vendor, that was not the case. When we started working on improvements, maybe it was clear they felt threatened by our presence.

Whenever we reached out with questions, responses were delayed. When we submitted code for review, it would sit there and wait for days. Comments often felt more like hurdles than constructive feedback. The underlying issue was clear: someone else was “touching” their code, and it triggered defensiveness.

Considering all those factors it is easy to assume some of the situations led to frustration. Sprint after sprint, the progress was slow, especially for the developers, and not because of the complexity of code and task, but because of other team’s dynamics. Or lack of it. It took days to move code which was developed from column “In a review” to “Done” column.

Still, being professionals, as we are, we had to keep calm. Getting emotional would only make things worse. So we’ve tried to take the opposite approach. Pause for a second. Take a deep breath. And continue to lean on the processes we established and transparent communication.

Finding the Right Approach: Patience Meets Professionalism

One of the first things we did was setting more clear expectations. We began raising review requests publicly in the shared Slack channel, tagging not only the other team but also the client’s Product Owner (PO). This wasn’t about escalation for the sake of drama, it was about accountability. Everyone could now see what was pending, and the silent delays became visible. The breakthrough came when we all agreed that code reviews had to be completed within 48 hours. That single agreement transformed our velocity.

The same story repeated itself in testing. Our QA engineers would carefully test new features, only to discover later that the other team had additional documentation, information that wasn’t initially shared with us. Their QA process acted like a second checkpoint, but instead of being collaborative, it often felt like a trap. Our work was being evaluated against criteria we hadn’t even been given.

Here again, transparency became our strategy. We began pushing for shared documentation and open conversations about testing requirements. It wasn’t easy, and sometimes it felt like Sisyphus’ job, but slowly, the situation started to improve.

The Language Barrier

Communication is always a crucial element of any collaboration, and in this case there was an additional layer of complexity in the form of a language barrier. The other team didn’t have strong English skills, which made collaboration slower and occasionally frustrating. During the first few months, the client’s PO, who speaks both English and the vendor’s native language helped us overcome this challenge. She acted as glue that kept things running smoothly.

But then came the day she went on prolonged absence. Suddenly, that bridge disappeared.

So we had to find a way to continue working for 2 months without our translator. For sure we wanted to avoid the “Lost in translation” situation. So we focused on the tools that we had: Written communication and Slack channel. We tried to write clear direct messages in Slack, and we always tagged another PO who stepped in. In that way we were transparent. Also, we’ve decided internally which tasks are lower priority, and can wait for the main PO to return. So some discussions that didn’t have a direct impact on the project’s progress were put on hold for a while, while the more critical ones were handled promptly together with the replacement PO, tech lead and other key stakeholders.

Walking a Fine Line: Implementing Improvements Without Disruption

Another balancing act was deciding what to improve and when. Our primary focus was to implement changes identified during due diligence. Any change that we planned must be done in a way we don’t disrupt other vendor’s ongoing activities. In this dual vendor setup, stepping on each other’s toes seems like a huge risk at the moment. It’s like you have to renovate someone’s kitchen while they still live there, and they expect they can prepare meals without any disruption.

So, we became strategic. We carefully selected which areas to tackle, focusing on high-impact improvements that could be delivered in isolation without blocking anyone else. It required restraint and discipline. Sometimes we had to postpone the changes that could bring long-term value, simply because the short-term risks of disrupting the other team was too high.

This approach wasn’t easy or our first choice, to be honest. It required working on tasks through workarounds or by using non standard methods. But in the end, it showed the client that we managed to adapt to the improvements while our hands were slightly tightened.

Keeping Morale High Intensity Atmosphere

Inside our team, the emotional toll was real. Daily meetings and retrospectives become our place to vent out. Sometimes we were facing frustration, however we didn’t want the negativity to win.

We encouraged open conversations in retrospectives. We validated the team’s frustrations but channeled them into constructive problem-solving. We know our results speak for themselves. Even minor changes that we did, showed a huge improvement in the client’s application. We knew quality was on our side. Plus, we knew this limbo is not forever. It was only for a few months.

When things were not going our way, we kept reminding ourselves. We can not control the other team, but we must strive to be as good as we can. We reminded ourselves that professionalism wasn’t about never feeling frustrated. It is how you react to the frustration.

The Turning Point

Persistence pays off. Slowly, the client began noticing the difference in our approach. They saw a team that stayed positive under pressure, that solved problems instead of escalating them unnecessarily and that delivered improvements despite the odds.

What truly made a difference, though, was our focus on the quality of our deliverables and on the bigger picture: understanding the reasons behind the other team’s resistance. Instead of pushing harder, we listened, adapted and kept our eyes on the shared goal. As a result, the applications we improved became faster and more reliable. The new blog we designed brought a fresh and modern look to the site.

It wasn’t about being perfect. It was about being reliable. Week after week, we shipped quality code. We improved processes. We communicated openly. And day by day we were earning the client’s trust.

When the decision point arrived, the outcome was clear. The client chose to continue with us. Not just because of the technical value we provided, but because of the professionalism, resilience and collaboration we demonstrated in a complex setup.

Lessons Learned: Thriving in a Dual-Vendor Environment

Looking back, this phase of the project where we worked in a dual vendor setup, was more than delivering software It taught us how being human and kind always pays off. It tested our patience, while working with different culture and not so cooperative teams. Here are some of the key takeaways:

1. Transparency beats assumptions. By making reviews and testing processes visible, we reduced room for silent delays and unspoken resistance. Use Slack or any other official communication channel.


2. Process is your friend. Clear rules like a 48-hour review SLA created accountability and removed ambiguity.


3. Communication and documentation are everything. Especially when you don’t speak the same language, literally. Clarity and documentation are needed more than ever.


4. Humility goes a long way. Choosing not to push improvements that could disrupt others showed respect for the bigger picture.


5. Professionalism wins trust. Staying calm, constructive and reliable even in the time of frustration was the key to success.

Closing Thoughts

In today’s world, where it’s hard to get and keep clients, it’s even harder to work if you have a dual-vendor setup. On a daily basis, you need to deliver quality code, but also deal with politics, trust issues and human ego.

Working on this project was one big lesson learned about professionalism and patience. Instead of arguing we focused on quality, communication and collaboration and proved that’s our strongest card to play with in this game. In the end, we turned out to be the winners and we managed to convert a challenge into an opportunity.

And in the end, it wasn’t just about delivering improvements. It was about delivering trust. Along the way, the challenges brought us closer as a team and inspired us to find new, creative ways to move forward. Those moments of collaboration and growth became just as valuable as the final results. All together was a great foundation for a lasting partnership. That is more than any line of code, the real measure of success.