Summary:
- Mexico gives a full working day of overlap with US teams, not a narrow window.
- The client owns priority; the vendor owns sequencing and technical risk.
- A written definition of what counts as a blocker matters more than daily meetings.
- Two to four client hours per week is the realistic commitment.
Most articles about nearshore development sell the concept. This one describes the mechanics, because the concept is easy to agree with and the mechanics are where engagements succeed or fail.
The week, hour by hour
A typical engagement runs on a weekly cycle rather than a two-week sprint. The reason is practical: with a full day of time zone overlap, feedback arrives fast enough that a longer cycle just delays course correction.
| When | What happens |
|---|---|
| Monday morning | Thirty to forty-five minutes with the client. What shipped last week, what is planned this week, what decisions are needed. This is the only mandatory synchronous meeting. |
| Daily | A written status in a shared channel: done, in progress, blocked. No meeting. Anyone who wants detail asks in the thread. |
| Continuously | Blockers posted the moment they appear, not saved for a meeting. This is the single highest-value habit in a distributed setup. |
| Friday | Deployment to a staging environment the client can open, plus a short written summary of what changed and what to look at. |
That Friday environment is what makes the arrangement work. A client who can click through the actual software every week does not need to trust a status report.
Who decides what
The most common failure in these engagements is not technical. It is unclear ownership of decisions.
Our split: the client owns priority, the vendor owns sequencing.
If a client says feature A matters more than feature B, that is final. If the vendor points out that A depends on infrastructure work that has not been done, that is also final. Neither side overrides the other on the thing they own.
Where this breaks down is when a vendor quietly reorders work because something is more interesting or more convenient to build. It is invisible for a few weeks and then the client notices the roadmap drifted.
Blockers: the rule that saves the most time
In a co-located team, a blocked developer walks over and asks. In a distributed team, that same question can sit for hours.
The rule we write into every engagement: if you are blocked for more than thirty minutes, post it publicly, even if it feels like a small question. Not in a private message, not in tomorrow's standup.
The reason for public posting is that the person who knows the answer is often not the person you would have asked.
What the client actually commits to
This is the part that gets underestimated in sales conversations, so it is worth stating plainly.
- One planning conversation per week, thirty to forty-five minutes.
- Answers to blocking questions within the same business day.
- A review of the staging environment before the next planning call.
- One named person with authority to decide. Not a committee.
That last point matters more than the rest combined. An engagement where every question routes through a group chat of five stakeholders moves at the speed of the slowest reply.
Frequently asked questions
How many hours of overlap are there with US time zones?
Mexico shares or nearly shares business hours with Central and Mountain time, and is one to two hours off from Eastern and Pacific. In practice that means a full working day of overlap rather than a narrow window, so questions get answered the same hour instead of the next day.
Who owns the backlog, the client or the vendor?
The client, always. The vendor proposes sequencing and flags technical dependencies, but priority is a business decision. When a vendor controls the backlog, what gets built is what is convenient to build.
What does the client actually have to do each week?
Roughly two to four hours: one planning conversation, asynchronous answers to blocking questions, and a review of what shipped. Less than that and decisions queue up; much more than that usually means the scope was never properly defined.
How are blockers handled without daily meetings?
With a written rule about what counts as blocking and a channel where blockers get posted immediately rather than waiting for a standup. A blocker that waits eighteen hours for a meeting costs a full day of one person.
What happens when the client goes quiet for two weeks?
Work continues on everything already specified and then stalls. That is why we keep a small buffer of specified-but-not-started work: it absorbs a client vacation without anyone sitting idle.
What goes wrong, honestly
Three things, in order of frequency.
Decision latency. Not language, not skill, not time zones. A question that waits four days for an answer stops a work stream, and it compounds because the next question is often blocked by the first.
Unstated assumptions. A client says "standard checkout" meaning the flow their previous company used. Nobody wrote it down. The team builds a reasonable interpretation and it is wrong. The fix is boring: write assumptions down and confirm them, even when they feel obvious.
Scope drift by accretion. No single request is big. Twenty small requests over two months are. Every change goes through the same written path, however small, or the schedule quietly becomes fiction.
None of these are specific to nearshore. They are specific to distributed work, and nearshore just makes them cheaper to fix because you can get everyone on a call the same afternoon.
What we ask for before starting
A short list, and the engagements that provide it go noticeably better than the ones that do not.
- One decision-maker with a name. Someone who can answer a product question without convening a meeting.
- Access to whoever knows the existing system. Often not a developer. Often the person in operations who has used it for nine years.
- A staging environment we can deploy to. Or permission to create one. Weekly review depends on it.
- The real constraints, stated early. Budget ceiling, immovable dates, a system that cannot be touched. Constraints shape design and are cheap to honor when known.
How progress gets reported
Not with percentages. A task that is ninety percent complete has been ninety percent complete in every project in history.
We report in terms of what a person can now do that they could not do last week. "The invoice list loads and filters, and you can open one" is verifiable. "The invoicing module is seventy percent done" is not.
This shifts the conversation from trust to observation, which is the only reliable footing for a relationship where the parties are in different countries and rarely in the same room.