Nearshore software
development in Mexico.

What “nearshore” actually means

Nearshore describes outsourcing software work to a country close enough that the working day overlaps with yours. For a US company that means Mexico, Central America, Colombia and the rest of Latin America. Offshore, by contrast, usually means Eastern Europe or South and Southeast Asia — regions where the overlap with US hours is a couple of hours at the edges, or none.

The distinction sounds like geography. In practice it is entirely about the cost of a question. On a nearshore team, “which behaviour did you mean here?” is answered in minutes and the work continues. On a team twelve hours away, the same question costs a day — and the developer, rather than waiting, usually guesses. Most of what people describe as offshore quality problems are actually the accumulated cost of guesses made because asking was too slow.

The time zone, stated in numbers

Jalisco — where Puerto Vallarta sits — observes Central Time year-round. Mexico abolished daylight saving time in 2022, so the clock here does not move; the United States still shifts twice a year, which means the offset changes even though our time does not. Both cases:

• Chicago: Same clock in US winter, PV one hour behind in US summer.
• Denver: PV one hour ahead in US winter, Same clock in US summer.
• New York: PV one hour behind in US winter, PV two hours behind in US summer.
• Los Angeles: PV two hours ahead in US winter, PV one hour ahead in US summer.

The honest summary is: within an hour of Chicago and Denver, and never more than two from New York or Los Angeles. What that buys is not a marketing line, it is a full working day of overlap — a 9am standup on the East Coast happens at 8am here, and a 4pm question from Los Angeles arrives at 6pm, still inside the working day.

Be sceptical of any vendor that claims “the same business hours as Chicago” without qualification. It is true from November to March and wrong for the rest of the year, and a vendor who has not noticed that has not thought about your calendar very hard.

How a nearshore engagement actually works

“Nearshore” describes where the team is, not how you buy from it. Three shapes dominate, and choosing the wrong one is a more common failure than choosing the wrong country.

Staff augmentation

You rent engineers who join your existing team, attend your ceremonies and work from your backlog. You keep architectural control and you keep the management burden — someone on your side has to prioritise, review and unblock every day. It works when you have a functioning engineering organisation and a shortage of hands, and it fails quietly when you do not, because there is nobody accountable for the outcome as opposed to the hours.

Project or outcome-based delivery

You define what needs to exist and the vendor is accountable for producing it — scope, sequencing, estimates and technical decisions included. It suits companies without a deep in-house engineering function, and it requires more discipline at the front: an outcome nobody has defined cannot be delivered against.

Advisory and fractional leadership

Someone senior takes responsibility for the technical direction — architecture, vendor selection, hiring plans, due diligence — without a full-time hire. Usually the right first step when the real problem is that no one can say whether the current system is worth keeping.

Whichever shape you pick, the operating rhythm that makes a cross-border engagement behave is unglamorous and consistent: a short written update at a predictable time, a live call each week with the people doing the work rather than a relay, a running list of open decisions with a named owner and a date, and something demonstrable at the end of every stage. The overlap described above is what makes that cadence possible; it is not what makes it happen. Agree it in the contract.

Nearshore vs. offshore vs. onshore

All three are legitimate. They are good at different things, and the honest comparison is not about price per hour.

Onshore

Highest rate, zero friction: same language, same legal system, same holidays, same cultural defaults about escalation and disagreement. Worth it when the work is deeply entangled with a regulated domain, when procurement effectively requires it, or when the project needs daily in-person presence. The constraint is usually not cost but availability — good engineers are scarce everywhere.

Offshore

Lowest rate and the deepest talent pools in absolute numbers. It works well for well-specified, stable workstreams — a maintenance queue, a defined migration, a test suite — where the specification can be written once and does not change weekly. It works badly for discovery-heavy work where the requirements are found rather than given, because that mode depends on cheap questions.

Nearshore

The middle: materially below onshore rates, with the overlap that makes iterative work practical. It suits projects where the scope will genuinely change, where a business person needs to be in the loop regularly, or where you want the option of getting on a direct flight and being there the same day.

The decision rule that survives contact with reality: if the requirements are settled, distance is cheap; if they are not, distance is the most expensive line item in the project. If you already know which way you are leaning, the questions US companies ask us most cover the practical objections.

What it costs — and why the hourly rate is the wrong comparison

The ordering is not controversial: onshore US rates are the highest, nearshore sits materially below them, and the lowest offshore rates sit below that again. Every vendor in the market agrees on that shape. What almost nobody says out loud is that the rate is the least predictive number in the comparison.

This page publishes no rate figures on purpose. Ranges for Mexican nearshore work vary by source, by seniority and by engagement shape, and most of the figures circulating are somebody’s marketing page cited by somebody else’s marketing page. A number without a stated methodology is worse than no number, because it invites you to budget against it. If a vendor gives you a range before knowing what you are building, you have learned something about the vendor rather than about the price.

What actually moves the total, roughly in order of impact:

• How settled the scope is. Rework is the single largest line item in most failed projects and it does not appear on any rate card. Discovery-heavy work at a low rate routinely costs more than the same work at a higher one.
• How much of your own team’s time the arrangement consumes. An engineer you have to unblock every morning is not cheap; the cost has simply moved onto your payroll instead of the invoice.
• Seniority mix. Two experienced engineers frequently outrun five junior ones on the same problem, at a lower total, because most of the cost is in decisions rather than in typing.
• What you own at the end. A lower rate that leaves you unable to hire anyone else to maintain the result is a financing arrangement, not a discount.
• Coordination overhead. Meetings at inconvenient hours, translated specifications and an account-management relay all consume budget without producing software.

The useful comparison is therefore total cost to a working, maintainable system — not cost per hour. When you ask for quotes, ask each vendor to price the same defined stage and to say what is excluded. The spread in the exclusions usually explains more than the spread in the rates.

Why Mexico specifically

• Time zones. Mexico spans US Central, Mountain and Pacific equivalents. No arrangement of shifts is required for a shared working day.
• Travel. Direct flights connect most large US cities to Mexican hubs in a few hours. An in-person kickoff or quarterly review is a day trip, not an expedition.
• Legal and commercial familiarity. The USMCA framework, standard cross-border contracting and routine USD invoicing make the commercial side ordinary rather than exotic.
• Established engineering base. Mexico has a long-standing technology industry serving both domestic enterprises and US clients — this is not a market being invented for outsourcing.
• Cultural proximity. Underrated and hard to quantify. Shared reference points, similar business norms and comparable directness in raising problems mean less is lost between what was said and what was understood.

IP, source code and data

This is the part of a cross-border engagement most often waved through in the sales conversation and most expensive to renegotiate afterwards. Three separate questions get collapsed into one, and they have different answers.

Who owns what is produced

Work-for-hire is not the automatic default everywhere, so ownership should be assigned explicitly in the contract rather than assumed from the invoice. Ownership means the source code, the schema and migrations, the infrastructure-as-code, the build pipeline and the documentation — not just the running application. Two clauses are worth insisting on: that the assignment takes effect as work is paid for rather than at final completion, and that it covers anything the vendor commissioned from a subcontractor.

Whether you can actually leave

Ownership on paper is worthless if the practical ability to move is missing. The test is simple and worth applying mid-project rather than at the end: could a different team clone the repository, run the setup, deploy to a fresh environment and understand why things are built the way they are, without asking the incumbent? If the answer is no, you have a dependency regardless of what the contract says. Accounts registered in your organisation’s name from day one — cloud, registrar, repository, error tracking — remove most of the risk for free.

Where the data lives and who can reach it

These are two decisions, not one, and neither is determined by where the engineers sit. Data residency is a hosting choice: your cloud region can be in the United States while the team is in Mexico. Access is a permissions choice: whether engineers work against production data at all, whether personal data is masked in lower environments, who holds production credentials, and how access is revoked when someone rolls off. If you are subject to HIPAA, PCI DSS, GDPR for European users, or contractual commitments to your own customers, those constraints belong in the architecture from the first week — retrofitting them is one of the most expensive corrections in software.

What to settle before signing anything

Beyond ownership and data, the failure modes of cross-border engagements are boringly consistent, and all of them are cheaper to prevent than to fix.

• Handover conditions. Not only what happens at successful completion, but what happens if you stop halfway. A project whose value only exists at the end concentrates all the risk on you.
• Acceptance criteria per stage. What specifically has to be true for a stage to be complete and payable. “Done” is the most expensive undefined term in the industry.
• Who is actually on the team. Ask for names and a technical conversation before signing. Some firms sell with senior engineers and staff with whoever is free.
• Communication cadence and language. Which meetings, in which language, with which artifacts written down. Verbal agreement across a border and a second language is where scope quietly diverges.
• Currency and payment terms. Which currency, whose bank fees, what happens on a delayed invoice. Small things that become friction at exactly the wrong moment.

When nearshore is the wrong answer

A guide that concludes “hire us” in every scenario is not a guide. Cases where you should not go nearshore:

• The work needs daily physical presence — hardware, a lab, a factory floor, a secure facility.
• The requirement is a very large, very stable maintenance queue. Volume at the lowest rate is what offshore is genuinely good at.
• You have no one internally who can make decisions. No delivery model fixes an absent decision-maker; distance only makes the vacuum more visible.
• Procurement or regulation requires domestic staffing. Find out early; it is not negotiable later.

What JADE7 does within this model

We are a software studio in Puerto Vallarta working with companies in Mexico and the United States, fully remote, on Central Time. We take engagements end to end — design, development, deployment and ongoing maintenance — rather than renting out developers by the hour. At the end of a project the source code, the documentation and the infrastructure access are handed over to you; continuing with us for maintenance is then a decision rather than a dependency.

• Custom software
• Web & e-commerce
• Automation & integrations
• Technology consulting

Frequently asked questions

What is the difference between nearshore and offshore development?

Distance measured in working hours rather than miles. Nearshore means a country whose business day overlaps with yours — for a US company, Mexico and the rest of Latin America. Offshore usually means Eastern Europe or Asia, where the overlap is an hour or two at the edges, or none. The practical difference is what it costs to ask a question: minutes on a nearshore team, a day on an offshore one.

How many hours of overlap will we actually get with a team in Puerto Vallarta?

A full working day. Jalisco is on Central Time year-round — Mexico abolished daylight saving time in 2022 — so we are within an hour of Chicago and Denver and never more than two hours from New York or Los Angeles, in either season. A 9am standup on the East Coast is 8am here; a 4pm question from California arrives at 6pm, still inside the working day.

Is nearshore development cheaper than hiring in the United States?

Rates are materially below US onshore rates and above the lowest offshore rates, but the rate is the least useful number in the comparison. What decides the total is how much rework the arrangement produces, how much of your own team's time is spent unblocking someone, and whether the scope is settled. A cheaper hourly rate on discovery-heavy work is routinely the more expensive project.

Why does this page not publish hourly rates?

Because we would be quoting someone else's marketing page back at you. Published nearshore ranges vary widely by source, by seniority and by engagement shape, and a number presented without a methodology is worse than no number. Ask any vendor for a rate tied to a named role and a named scope, and treat an instant range for an undefined project as a warning rather than a service.

Who owns the source code at the end of a nearshore project?

On our engagements, you do — the source code, the documentation and the infrastructure accounts are handed over, and continuing with us for maintenance is a decision rather than a dependency. That is not universal, so get it in writing wherever you go: ownership should transfer on payment, not on completion, and it should not lapse if you stop the project halfway.

What happens to our data if it is processed in Mexico?

That is an architecture decision to make before the build, not after. Decide where the data may physically live, who may hold production credentials, and whether any of it is subject to a regime — HIPAA, PCI DSS, state privacy law, contractual obligations to your own customers — that constrains the answer. Where data lives is a choice about hosting regions; who can reach it is a choice about access control. Neither is decided by where the engineers sit.

Do we need to travel to Mexico for this to work?

No. The work runs remotely, and the overlap is what makes that practical rather than aspirational. Travel is an option rather than a requirement: direct flights connect most large US cities to Mexican hubs in a few hours, so an in-person kickoff or a quarterly review is a day trip if you want one.

How is a cross-border contract usually structured?

As an ordinary services agreement. The clauses that matter are IP assignment, confidentiality, the currency and payment terms, the acceptance criteria for each stage, and what happens on termination. Settle the communication model in the same document — which meetings, in which language, and which artifacts are written down — because verbal agreement across a border is where scope quietly diverges.

What language will the project actually run in?

English, end to end, on projects with US clients — meetings, documentation and deliverables, with no translation step in between. That matters more than it sounds: a vendor who works in one language internally and hands over documents in another produces artifacts your team cannot maintain. Worth pinning down with any vendor you talk to, and worth asking to see a real document rather than a promise.

When is nearshore the wrong choice?

When the work needs daily physical presence, when the requirement is a very large and very stable maintenance queue that offshore volume serves better, when procurement or regulation requires domestic staffing, or when there is nobody internally empowered to make decisions. No delivery model fixes an absent decision-maker; distance only makes the gap visible sooner.