Onshore vs. Offshore Software Development: When Each Works
A state benefits portal that checks applicants’ income can end up holding federal tax information, and the IRS requires agencies to certify that contractor staff and systems with access to that information are located in the United States or its territories. That one rule decides where part of the engineering team sits before anyone compares candidates. A healthcare scheduling product faces a different rule set: HIPAA allows offshore work on protected health information under the right agreements, so the location question there is about risk and accountability, not permission.
That is the practical shape of onshore vs offshore software development for regulated products. Keep work onshore when a law, contract or data obligation requires it, and when someone must answer in person to a regulator, auditor or customer during their working day. Use offshore engineers for well-defined work that can be done without access to regulated data, which on most products is a larger share than teams expect. The rest of the decision follows from where you draw the data boundary.
What Do Onshore and Offshore Mean in Software Development?
For a U.S. company, onshore means engineers based in the U.S. and offshore means engineers based in distant countries, commonly in Eastern Europe and Asia. The terms describe location only. A contractor in Ohio is onshore and outsourced; an employee working from Poland is offshore and in-house. Gun.io’s first essay in its series on what onshore, nearshore and offshore actually mean makes the same point: location affects overlap, travel and legal constraints, and says nothing about whether an engineer is good.
For regulated work, one more distinction matters. Some rules turn on where a person is located, some on where data is stored or accessed and some on a person’s citizenship or residency status. Those are three different tests, and “onshore” satisfies only the first.
When Does a Rule Require Onshore Engineers?
A rule requires onshore engineers when the data or technology involved carries a location restriction that a contract cannot waive. Federal tax information is the clearest example for public-sector software. The IRS’s contractor notification procedures require agencies to certify that contractor personnel accessing FTI, and contractor information systems containing it, are located within the United States or its territories, “given that FTI is not allowed offshore.” Source: IRS, 45-Day Notifications The same procedures require agencies to notify the IRS before disclosing FTI to a contractor and to get approval before any subcontractor gets access.
For a benefits portal, that restriction follows the data, not the project. Engineers who build the eligibility screens may never need production FTI, while the engineers who operate the income-verification integration, debug it in production or run its database almost certainly do. The agency’s contract and its safeguards plan decide which roles count as having access, so read both before you plan the team.
Export controls show why location alone does not settle the question. Under the Export Administration Regulations, releasing controlled technology or source code to a foreign person inside the United States is itself an export, known as a deemed export. Source: eCFR, 15 CFR 734.13 A product with export-controlled components can therefore need engineers who meet a person-based test, which an onshore team does not automatically meet. This is general information, not legal advice; confirm how these rules apply to your system with counsel.
What Does HIPAA Allow for Offshore Engineering Work?
HIPAA does not prohibit offshore work on protected health information. The HHS Office for Civil Rights says a covered entity or business associate may use a cloud provider that stores electronic PHI on servers outside the United States, provided a business associate agreement is in place and the rest of the HIPAA Rules are followed. The same guidance notes that the rules contain no requirements specific to ePHI processed or stored outside the country, and that the risks can vary greatly by location, which entities must account for in their risk analysis. Source: HHS, Guidance on HIPAA and Cloud Computing
For a healthcare scheduling product, that shifts the question from “may we?” to “what does our risk analysis and our customers’ contracts say?” An appointment record that ties a named patient to a cardiology clinic is health information, and once the product handles it for a provider, the vendor is generally a business associate. Health system customers can add their own contract terms on where vendors may access their patients’ data. Those terms, more than HIPAA itself, often decide which engineers can touch production.
How Does Data Residency Shape the Architecture?
Data residency shapes the architecture because the cheapest way to widen your talent pool is to shrink the part of the system that holds regulated data. If every service can read PHI or FTI, every engineer needs clearance and every location question becomes a compliance question. If regulated data lives behind a small number of services with their own access controls, most of the codebase can be built and tested by anyone.
The boundary usually needs four things. Regulated data sits in a separate environment that only cleared roles can reach. Development and test environments run on synthetic data that preserves the shapes and edge cases of real records, such as a household with three income sources or a patient with two active referrals. Logs and error reports are scrubbed before they leave the regulated environment, because a debug log that prints an applicant’s tax data into a shared log search tool moves that data to everyone who can query it. Production access for incidents goes to a named onshore rotation, with the offshore team working from sanitized traces.
That design work is itself onshore work in most regulated products, because the people making it need to read the agency contract or the customer’s security addendum and defend the decisions to an auditor. Gun.io describes how it handles access and data in its security and privacy practices.
Why Does Customer-Facing Accountability Often Stay Onshore?
Customer-facing accountability often stays onshore because the people who answer for a regulated product have to be available when their counterparts are. A state agency launching a new benefits portal has program staff, auditors and sometimes legislative deadlines. When an eligibility rule produces the wrong determination for a group of applicants, someone has to join the agency’s call that day, explain what happened and commit to a fix the agency can defend to residents.
Healthcare scheduling has the same pattern with different people. A clinic go-live involves front-desk staff learning new workflows, practice managers who notice when a provider’s template blocks the wrong slots and IT teams who need a single technical contact during the cutover. The engineer who owns that relationship needs to share the customer’s hours and, in some contracts, be available on site.
None of that means the engineering behind those conversations must be onshore. It means one accountable owner per customer-facing system should be reachable on the customer’s schedule, with the authority to change priorities for the rest of the team.
What Does Offshore Handle Well in Regulated Products?
Offshore engineers handle well-defined work that stays outside the data boundary, and on a well-designed regulated product that covers a lot of the build. On the benefits portal, that includes the accessible form components, the document-upload flow tested against synthetic files, load testing of the application submission path and the automated test suite for eligibility rules expressed as fixtures. On the scheduling product, it includes the calendar rendering, the slot-search performance work tested against generated provider calendars, integration adapters built against published API specifications and the migration tooling for moving customers off older versions.
Specialist depth is another reason to look offshore. If the scheduling engine needs someone who has solved constraint-based scheduling problems before, the strongest candidate may live several time zones away, and the work can be specified clearly enough to suit that arrangement.
The condition is the same in every case: the work has written acceptance criteria, it can be verified without production data and the engineer has someone onshore who answers questions about the domain on a predictable schedule.
How Should You Split a Regulated Product Between Onshore and Offshore?
Split it by data access and accountability first, then by how defined each workstream is. The table below shows one way the two example products could divide; your own contracts and risk analysis decide the final version.
| Workstream | Benefits portal | Healthcare scheduling product | Usually fits |
|---|---|---|---|
| Data boundary design and access policy | Defined by the FTI safeguards plan | Defined by BAAs and customer security terms | Onshore |
| Production support with regulated data access | Income verification and eligibility records | Live patient appointments and referrals | Onshore |
| Customer-facing technical ownership | Agency program and audit contact | Clinic go-lives and IT contacts | Onshore |
| Feature work on synthetic data | Application forms, status pages | Calendar views, booking flows | Onshore or offshore |
| Test automation and performance work | Rule fixtures, submission load tests | Slot search, generated calendars | Offshore fits well |
| Integrations against published specs | Document services, notification providers | Calendar sync, messaging providers | Offshore fits well |
Keep the onshore group small and senior. Two strong full-stack engineers who understand the regulated data path end to end usually give better coverage than a larger group split by layer, and they can review the boundary-crossing changes the offshore group submits. The handoff between groups should be the data boundary itself, documented well enough that a new engineer on either side can see what they may and may not access.
How Does Cost Fit Into the Onshore vs Offshore Decision?
Cost fits in after the constraints, because a model that breaks a data rule is not a cheaper option. Within the constraints, cost depends on the complexity of the problem, the time it takes to solve and the experience it requires. Compliance adds its own work to that equation: safeguards documentation, access reviews, background checks where contracts require them and the engineering time to build and maintain the data boundary.
The boundary pays for itself when it lets more of the build happen outside the regulated environment. Without it, every new engineer, wherever they are, adds clearance work and audit scope. When you compare options, count the internal compliance and security hours each one creates alongside the engagement cost. The comparison between staff augmentation and other engagement models covers who carries delivery and management time in each arrangement.
How Does Gun.io Approach Onshore and Offshore Work?
At Gun.io, we start by understanding the problem and its constraints, including which data the work touches and which rules apply to it, and then decide who should do the work and under which engagement model. We have talent-side representation in every country, so the answer can be an onshore engineer for the regulated data path and engineers elsewhere for defined workstreams, or one location for everything when the constraints call for it. We handle the contracting, payments and compliance that come with engineers in different countries, though your own regulatory obligations stay with you.
Our project experience includes healthcare and public-sector domain work, and you can see how we approach engineers for healthcare software. One published brief describes moving clinical validation logic out of a mobile app and into the backend so that the server, rather than the device, governs the state of each activity. Work like that is where knowing the data path matters as much as writing the code.
Frequently Asked Questions
Does HIPAA Require Healthcare Software to Be Built Onshore?
No, HIPAA does not require onshore development or onshore storage of protected health information. It requires business associate agreements and compliance with the HIPAA Rules, and HHS expects the risks of offshore access or storage to be addressed in the risk analysis.
Can Offshore Engineers Work on Government Software?
Yes, depending on the data and the contract. Federal tax information may not be accessed offshore, and agency contracts can add their own location or personnel requirements, so offshore engineers usually work on parts of the system that stay outside those restricted data flows.
Is a U.S.-Based Engineer Always Cleared for Export-Controlled Code?
No. Releasing controlled technology or source code to a foreign person in the United States counts as an export under the Export Administration Regulations, so the relevant test can be a person’s citizenship or residency status rather than where they work. Knowing which repositories hold controlled technology lets you restrict access to them the same way you restrict access to regulated data.
What Is the Difference Between Data Residency and Data Access?
Data residency is where data is stored, and data access is who can read it and from where. A database hosted in a U.S. region can still be accessed from abroad, so many obligations depend on access controls as much as on hosting location.
How Do Offshore Engineers Test Features Without Real Patient Data?
They test against synthetic data built to match the structure and edge cases of real records. Good synthetic data includes the awkward cases, such as overlapping appointments or a referral that expires mid-booking, so features behave correctly before they reach production.
Should Production On-Call Be Onshore for Regulated Systems?
Production on-call should sit with engineers who are permitted to access the regulated data an incident may expose. For many regulated systems that means an onshore rotation, with offshore engineers contributing through sanitized logs and traces.
Let the Data Boundary Decide Where Engineers Sit
Draw the regulated data boundary first, keep the roles that cross it and the people who answer to customers onshore, and open the rest of the work to the strongest engineers wherever they are. If you are planning a regulated product, talk to us about what you’re building, the data it handles and the contracts that govern it.
