Nearshoring, Offshoring, or Local Development? Analyzing the pros, cons, and key metrics.

I won’t tell you when I graduated from MIT or when I kicked off my career working at Uber’s first offices in San Francisco, or I’ll never work in this industry again. But I have been around long enough to be sure of one thing: what’s old is new again, and trends in technology development come and go. Remember when no one was going to ever use relational databases ever again? When everyone was going to work from home? Or live in the metaverse? If you want to avoid the pitfalls of being a follower, the first question to ask is “what are you trying to accomplish” not “what is everyone else doing”.

The one constant I’ve found is that companies chasing the latest fad will never have great outcomes - nowhere more so than in the decision about where to source software teams.

At Valere, we offer a range of solutions in multiple countries and time zones, and our crucial Discovery planning process is meant for companies to understand the right fit not just for the product you’re building but the kind of team and culture you want to create for long-term success.

Video conferencing has been around since it was invented at Stanford in 1968, and IBM built a smartphone in 1992 (code named “Sweetspot”). But when the internet first made remote collaboration possible in the mid 90s and early 2000s, the clear benefits in cost and relative expertise led to a boom in remote development teams. The industry really took off with advent of easy-to-use instant messaging like Slack and the widespread adoption of cheaper Android/Huawei phones, and the project management revolution of the 2000s (Asana, Atlasian) is still pushing the frontier of how we collaborate both at medium- (riding the bus into Cupertino from San Francisco, or just staying in your pandemic hideaway in Boise) and long-distances.

In countries like India and Croatia there are now firms with decades of experience helping American or European companies build world-class software, and this model has only gotten more mature over time. However, it’s not for everyone - I don’t need to tell you about the obvious challenges when working across time zones, or coordinating with teams with different levels of English. So the pendulum has swung back - from “offshoring” to “nearshoring” and to a hybrid approach with (more expensive) developers and product people complementing partial remote teams. In the meantime, technology and tooling (in project management, automatic translation, and AI-driven collaboration) has only made it easier to work with teams at a distance. There’s now a cottage industry of reports and consulting identifying underlying trends with eerie statistical specificity, and it should be easy to choose what’s right for you, right?

In my mind this narrative elides the actual issue. Companies all have different ways of working and different needs, strengths and weak spots, and not taking the time up front to understand how to collaborate will doom even the past laid plans. On the flip side, companies should evaluate whether any outsourcing agency, regardless of location, has addressed the potential drawbacks and is in a position to take advantage of the clear advantages of all three approaches to work. We pride ourselves at Valere as being somewhat reluctant suitors - we need to get to know you before we can be sure it’s the right fit, and we will suggest which of our teams is most likely to be successful, setting aside all ego or internal politics.

To make things personal, I’ve worked on both sides of the aisle - as part of large multinational teams at Uber and Apple, as a manager for teams in Latin America hiring the right internal teams, and as Managing Director at Valere selling near-shore solutions to US-based companies. In my mind, the questions to ask before tying the knot are, in rough order of importance:

1. The Deal Breakers

• How cost sensitive are you? As a first cut, largely independent of the quality of talent (assuming you pay attention to the rules for successful engagement I’m discussing here), it’s important to decide how much money you want to spend. In my experience, working with teams in southeast Asia or India might cost 40-50% of what you would spend for an equivalent product with US developers. In Colombia (where I live) and other parts of Latin America the figure might be more like 70-80%. For both large and small projects this is not an immaterial consideration - it involves decisions about how much/when to fundraise, whether operational budgets in markets in which you operate can cover expenses, and if you have a buffer if projects go over budget or take longer to deliver (of course that never happens with us!).

• How much US knowledge is required/what regulatory hurdles do you face? This is important, as some industries may prohibit work with specific countries or even outlaw any remote work (particularly important are health-care/HIPAA and anything to do with finance or national defense). It is important as a second step to consider any certifications (ISO-2001, SOC2) as well.

2. Know What You Want and What You Need

• Are you a technology company or a technology-enabled company? I know this one sounds stupid, but bear with me. The difference is whether you care how the sausage is made, and this may tilt the balance towards collaborating in closer time zones and getting to know how to work directly with developers. If you are a startup, and you’re looking to get something off the ground that eventually you will own and sell as your own product, you will want to pay more attention to development per se, and ensure that any deliverable includes well documented (in English) processes and code. Ask any potential collaborator on their experience with automated DevOps pipelines, and whether they will deliver infrastructure as code using Pulumi or Terraform so that you can maintain the product yourself over time. Trust but verify their use of project management tools like Jira, and whether they are relying heavily on AI-driven user stories or have the ability to construct their own. On the other hand, if the technology itself is a one-off tool or something supporting a more traditional business, you may not care. In that case off-shore companies may provide waterfall options or one-off consulting work relying on manual QA that you can integrate into your business seamlessly and at a lower cost, with minimal supervision or engagement by a smaller US-based team and with great results. Lower cost options under strict time delivery deadlines become more attractive in these cases, and these can be managed well from anywhere.

• What is your product? One of the largest challenges I’ve faced as a provider of near-shore products is working with product teams from the US or Europe. In my experience, very technical work (heavily mathematical ML models, corporate security consulting) can be done effectively by teams at a distance. But when the product becomes very US-focused (either for regulatory reasons mentioned above or because the user experience is forefronted), then you’ll want to consider one of two options. The first is to choose a country where there is a cluster of expertise. In LATAM, for example, the importance of remittances to regional economies and hard-earned experience with KYC/AML practices means that fintechs are a good fit in many cases. However, clients expecting fully seamless customer experiences in payments or banking may require close collaboration with a US-based product or design team, and it’s important to choose an agency familiar with your preferred method of collaboration in this case (Figma, Miro, etc.) to avoid any miscommunications or scope creep due to a lack of clarity or errors in the user flow. If you are a large company where you will be building something like a call center, consider countries with experience in this area (India, the Philippines), understanding that the product itself is an operational model, not a customer user flow.

3. How Much Time Do You Have?

• MVP or not to MVP? That is the question. This is related to my earlier point about the product to be delivered, but it’s important to keep in mind whether you have a fast-approaching, hard deadline or if you want to put more time into a close collaboration for a robust complete product that can be maintained with a local/remote collaboration over time. The key issue here is risk mitigation - it may simply take time to create a functioning asynchronous development flow for a fast turnaround MVP, even with advances in automated testing, so I recommend adding 30-40% buffer to your worst-case scenario if you have to deliver something functional at a given time, and considering whether you can afford any slippage.

  On the other hand, if you are planning on creating a production-ready platform on the first pass and are comfortable with a more flexible deadline or retainer model, keep in mind questions related to monitoring and alerting: will US based teams be watching Grafana or DataDog dashboards while your team in India sleeps? Who is responsible in the event of downtime? Are CI pipelines blocked by manual QA steps that will prevent a local developer from stepping in the case of an emergency?

• True love or just a fling? Pay attention to how the relationship between your company and any local developers is evolving and trust your instincts. If despite all of the above - implementation of best practices in project management, automated coding and delivery tools, a good fit in terms of technical expertise - you see red flags in your collaboration, move on and move on quickly. Set clear milestones that allow for graceful, face-saving exits on both sides so that you are not tied down in the long term, and avoid sunk-cost fallacies all too common in large companies.

To summarize, probably the most important questions are ones where you look inward. Where can you afford to take risks? Where are the upsides the most interesting? What kind of company do you want to be? We’re here to help you figure it out.