Henry Bassey

6 min readMay 27 2025

What Founders Get Wrong About Hiring Remote Teams — with CTO of Coax

Most founders think hiring remote developers is about finding the right price, signing a contract, and letting the code flow. IT’S NOT!

In this episode of Everything Outside Code, William sat down with Ivan Verkalets, co-founder and CTO of Coax Software. With over 14 years of experience across travel, retail, fintech, and logistics, Ivan has built and led distributed engineering teams that deliver consistent results. He’s helped Coax grow into a global development partner, known for its commitment to reliability, strategic input, and ISO-certified quality and security practices.

Ivan explains what founders often overlook when hiring remote teams, why communication and context usually outweigh geographic proximity, and how to build outsourcing relationships that work in practice, not just on paper.

Whether hiring offshore, augmenting an in-house team, or trying to rescue a project already in motion, this conversation offers a grounded perspective worth hearing.

The myth of plug-and-play outsourcing

One of the first things Ivan points out is how often founders approach outsourcing with vague ideas and high expectations.

“The biggest mistake is when founders don’t have a clear result in mind. They want to build something, but can’t articulate the problem or what success looks like.”

This situation isn’t uncommon. A founder has a vague product idea, like “an MVP for a SaaS platform” or “an app that connects users to X,” but things start to unravel when asked about the user journey, business case, or technical constraints.

Ivan’s team starts by asking two questions:

• What problem are we solving?
• How will we know we’ve solved it?

According to him, the project isn’t ready for an external team if those questions don't have solid answers. Without that shared understanding, no amount of engineering talent will save it.

Offshore vs. nearshore vs. onshore

The classic debate is whether to go offshore to save costs, stick with local talent, or find a timezone-friendly nearshore partner.

If this is your first time coming across these models, here’s the basic idea:

Offshore means working with teams far from your home country, often across time zones. Nearshore is choosing a team in a nearby country or region, where work hours and communication styles might align more easily. Onshore means hiring within your borders.

Most teams weigh tradeoffs based on cost, timezone overlap, and cultural fit. Offshore is usually cheaper and more scalable. Nearshore can strike a balance between access and convenience. Onshore is easier to manage, but often the most expensive.

However, Ivan doesn’t think the real challenge is location.

“If you’re working remotely, it doesn’t change whether the team is 100 miles or 3,000 miles away. You’re still talking over Zoom. You’re still pushing to the same Git repo. What changes the outcome is how you work together.”

In other words, remote is a coordination problem, not geography.

Ivan’s team at Coax uses what he calls an escalation of communication. Every client is assigned a delivery manager as the main point of contact. But anyone can join sprint planning, standups, retrospectives, or even contribute code. Some prefer a single point of contact. Others become fully embedded in the process. The system flexes either way.

“We’re transparent. This isn’t a black box where you hand over a spec and wait for something to come back.”

That mindset matches our own experience at Hackmamba. Whether we’re writing API documentation or developer content, the most reliable partnerships are the ones where expectations are shared early, feedback is welcomed, and everyone feels part of the same team.

Penny-wise, product-foolish: the trap of comparing quotes

Ivan brings up a scenario that’s painfully familiar:

A founder collects three quotes: $50K, $60K, $80K. They pick the cheapest. Three months later, they realize key components like QA, documentation, security, or deployment weren’t included. The product isn’t usable, and they’ve already burned the budget.

“A lot of founders compare price, not scope. But one quote might include proper test coverage, while another doesn’t even budget for QA.”

Ivan advises you to dig into the estimate. Ask:

• Does this include project management?
• Is there post-launch support?
• What’s the process if the scope changes mid-build?

This is something we stress with our clients. Price without context is a trap. You’re buying outcomes, which depend on what’s in the scope, not just the number at the bottom.

You can’t pivot well if your team can’t adapt.

Startups move fast. Sometimes, too fast. Features change, roadmaps stall, and new AI breakthroughs wipe out your differentiator overnight.

Ivan isn’t surprised when founders panic and want to change direction mid-sprint. His team anticipates it.

“We use time-and-materials by default. If you want to swap out a Facebook login for Google, we do it. If it’s a bigger pivot, we re-evaluate the scope together.”

The deeper point here is about resilience. Ivan encourages founders to share long-term product plans upfront, even if those plans change.

You know why?

Because when engineers know your roadmap, they design with flexibility. They make choices that won’t box you in. That saves you money and pain down the line.

On quality, AI, and why junior engineers need senior problems

One of the most thoughtful parts of the conversation came when William asked about AI’s role in changing how software gets built and what that means for hiring.

Ivan says he treats AI tools as part of the workflow.

“If it saves time without compromising quality, we use it. Copilot, NotebookLM, anything that helps.”

But he also draws a line. AI-generated code can be used to prototype, but it can't replace the judgment of experienced engineers.

“Even working with AI, you need to know what makes good code. AI doesn’t always know the difference.”

Ivan believes junior engineers shouldn’t just be learning syntax or frameworks. They should also be learning how to think like senior engineers. That means system design, architecture tradeoffs, and security modeling.

“You don’t need to know how transistors work to be an engineer. But you do need to understand systems.”

This hit home for us. We’ve often said that today, knowledge is cheap and judgment is priceless. What you should hire for is decision-making ability.

Sales is timing

Another captivating moment in the podcast was when William described why he finally opened one of those classic “we have developers for hire” emails.

“It was timing. I was already thinking about hiring. That’s it.”

Ivan’s team leans into this insight. Instead of mass outreach, they do manual filtering. They study posts and look at what a company is shipping. They check who’s hiring, then send thoughtful, timely messages to maybe 50 people, against 5000.

The result is fewer bounces, more conversations, and less damage to their brand.

And we co-sign this strategy hard. Developer marketing is about signal before scale.

Final thoughts

There’s a lot of noise in the remote hiring. Everyone has a dev team. Everyone promises quality. Everyone wants to “explore synergies.”

Ivan and his team at Coax are building a system that works because it’s based on people, process, and plain talk. That’s what makes the difference.

Whether you’re building your first product or replacing an in-house team, the lessons in this conversation are:

• Define your problem before you define your dev team.
• Don’t optimize for cost. Know exactly what you're getting.
• Share your roadmap early.
• Expect your team to push back.
• Use AI but don’t trust it unquestioningly.
• And most of all: build relationships, not handoffs

Watch the full episode here.

Learn more about Coax Software.

Subscribe to our newsletter to receive more of these hard-won insights.