For years, offshoring was code for "cutting costs". but that's changing. At Everest, we’re seeing more and more organisations move away from “offshoring for cost” and towards a model that’s more nuanced, adaptive, and outcome-driven. One that is more focused on collaboration and customer outcomes. This has come to be known as rightshoring, awkward phrase, excellent strategy.

What Is Rightshoring?

It’s not about geography, it’s about value and fit.

Rightshoring means thinking strategically about where work gets done, based on what that work actually requires.

That might mean:

1. Keeping product discovery close to the customer (onshore - or, in the geographic market);
2. Building out cross-functional, full stack AI-enabled teams across multiple  locations with strong engineering talent to balance capability and cost;
3. Having folks across time zones that enable work / life balance and after hours support; and 
4. Exploiting (positively) diverse points of view on your project teams that build creative solution potential. 

Rightshoring asks the question:

“What are we trying to achieve, and what location (or mix of locations) supports that best?”

What to consider when Rightshoring

From years of experience with distributed teams, we’ve learned that a few consistent factors shape successful rightshoring decisions:

Capability and Talent Depth Where is the relevant expertise easiest to hire, grow, and retain?

Time Zone Alignment Does this work benefit from real-time collaboration, or does async make more sense?

Communication Complexity Is this high-touch work that requires close collaboration (e.g. product discovery)? Or well-scoped work with minimal dependencies?

Is English as a first language more critical to allow clever information flow? 

Security, Compliance, and Risk Are there constraints (data residency, regulatory, IP sensitivity) that impact data and work location?

Team Maturity and Autonomy Can this team own end to end outcomes? Or do they require ongoing support/coaching? How much trust is the right amount? 

Cost, With Context Lower cost matters. But it needs to be balanced against rework risk, talent turnover, or missed customer context.

What Rightshoring looks like in practice

We’ve helped organisations scale delivery across Australia, India, and Malaysia, and found that the best approach depends on what you’re building and who it’s for.

Here are three common models that work for us:

• Shared Product Ownership Teams Designers, engineers, QAs and BAs collaborate across locations as one cross-functional team.

• Dual-Track Discovery + Delivery Discovery stays close to the client (often in AU), while delivery runs from India or Malaysia.

• Specialised Functions in the Right Region For example, a support team based in a customer time zone to provide faster response outside business hours.

Each model brings trade-offs. Rightshoring is about making those trade-offs deliberate. Not unexpected. 

Why this matters now

With hybrid and remote work now the norm, and the coming explosion of agentic workers mingling with humans, the location of a team matters less — unless it matters more.

Misplaced work creates frustration, delays, and churn.

Well-placed work unlocks speed, engagement, diversity and quality.

Rightshoring gives us a more flexible, practical lens for planning distributed delivery — one that moves beyond the binary and into something much more fit-for-purpose.

‍

We’ll be sharing more soon about how we design and run distributed teams at Everest, and how we’re continuing to learn and adapt.

If you're wrestling with how to scale effectively across geographies Everest can help. If you already doing it, and have stories, we'd love to compare notes.

‍