Software and AI Companies Keep Overlooking Puerto Rico. That Is Starting to Change.

Technology leadership has a geographic reflex. When a company decides it needs to add engineering capacity, the options that surface are a mainland hub, a nearshore team in Latin America, or an offshore team further out. Puerto Rico almost never comes up, and when it does someone usually asks a question that reveals they are not sure whether it is a foreign country.

That blind spot is worth examining, because the island quietly solves several of the problems that make the other three options annoying.

The nearshore comparison that actually matters

Companies choose nearshore locations for overlapping time zones, lower cost, and reasonable talent availability. Those are real benefits and the model works for plenty of teams.

What nearshore does not give you is US jurisdiction. Your IP assignment agreements operate under foreign law. Your data residency story is more complicated. Your enterprise customers, particularly regulated ones, ask more questions. If you work with government or defense-adjacent clients, the conversation often ends entirely.

Puerto Rico gives you the nearshore cost and time zone profile while remaining inside the United States. Employees are US citizens. IP assignment runs under US law. Data stays on US soil. Contracts are enforceable in US courts. For a company selling into healthcare, financial services, or government, that difference is not academic, it is the difference between a sale and a security review that never ends.

Who is actually hiring engineers there

The honest picture is that Puerto Rico is not a consumer tech hub and is unlikely to become one. Nobody is building the next social app there at scale.

What is growing is more specific and, for a lot of companies, more durable.

Software supporting regulated industries is the strongest category. The island has decades of pharmaceutical, medical device, and manufacturing operations, which means there are engineers who understand validated systems, electronic records requirements, and what it means to build software that has to survive an audit. That skill set is rare and badly needed, and it is concentrated here for historical reasons.

Cybersecurity is a second area with real traction, helped by the US jurisdiction point and by a steady university pipeline.

Data engineering and applied AI work tied to industrial and life sciences operations is the newest and fastest growing. When a company has manufacturing and development on the island, the data and modeling work naturally follows, and that work is increasingly sophisticated: process modeling, predictive quality, computer vision for inspection, optimization against real operational constraints.

Where the research credit fits

Puerto Rico's current framework is Act 60-2019, the consolidated Incentives Code that replaced earlier statutes including Act 73-2008 (Legacy). Research and development activity is addressed under §3030.01, with two fixed rates: 50 percent on direct R&D investment deployed in Puerto Rico into experimental activities, and 20 percent on indirect R&D investment deployed outside Puerto Rico or into incidental activities.

Software companies tend to have an unhelpful instinct here, which is to assume either that all software development qualifies or that none of it does. Both are wrong, and the second is more common among companies that have never looked.

Development work involving genuine technical uncertainty generally has a strong case. Building a system where the technical approach was not known in advance. Developing novel algorithms. Solving performance, scale, or reliability problems that required experimentation rather than configuration. Model development where the architecture and approach had to be discovered through systematic iteration. Integration work where the feasibility was itself in question.

What does not qualify is the large volume of software work where the answer was known at the start. Building a standard CRUD application with established patterns. Configuring purchased software. Routine maintenance and bug fixes. UI work that is design execution rather than technical investigation. Rewriting something in a new framework because the team preferred the new framework.

The uncomfortable part for software teams is that a lot of very valuable engineering work is not experimental. Shipping a well-understood feature competently is enormously valuable to the business and is not research. Conflating the two produces a claim that looks indefensible the moment someone technical reviews it.

The documentation issue specific to software

Software teams have better raw records than they realize and worse organized records than they need.

You have version control history. You have issue trackers. You have design documents, architecture decision records, and pull request discussions where engineers argued about approaches. That is genuinely excellent evidence of technical uncertainty and systematic investigation, far better than what most industries can produce.

What is usually missing is the connection between that technical record and a project-level view of cost and time. Engineering time is tracked loosely or not at all. Work is organized by sprint rather than by project. Nobody can say what portion of a given engineer's quarter went to experimental development versus feature execution versus support.

Fixing that does not require heavy process. It requires defining development projects with a stated technical objective, tagging work to them in the tracker you already use, and having engineering leadership make an honest allocation call rather than a convenient one.

A note on AI specifically

There is a lot of enthusiasm right now for treating anything AI-adjacent as research by default. It is not.

Calling an API is integration. Prompt engineering against a commercial model is usually configuration, however clever. Fine-tuning with established techniques on your own data may or may not involve real uncertainty depending on the facts.

Genuine model development, novel architecture work, solving hard problems in data quality or evaluation where no established approach existed, or building systems that have to meet performance characteristics nobody knew were achievable, is a different matter entirely.

The distinction will matter more over time, not less, as this work becomes routine for more organizations. Teams that are rigorous about the line now will be in a far better position later.

The practical appeal for a growing company

If you are a technology company considering where to add engineering capacity, the island offers a combination that is genuinely hard to replicate: US jurisdiction and IP protection, a cost base below mainland hubs, a workforce with unusual depth in regulated and industrial software, time zone alignment with the US east coast, and a structured research incentives framework if your work qualifies.

The constraints are real too. The talent pool in some specializations is thinner than a major hub, which means hiring takes longer and you should expect to invest in developing people rather than only buying finished ones. Power reliability affects office operations and should be planned for. And the ecosystem, while growing, does not have the density of a Boston or an Austin.

Everything here is indicative advisory context. Qualification, rates, and decree terms depend on your facts and current administrative practice and should be confirmed before you plan around them.

Why this is likely to keep growing

The strongest reason is not tax. It is that the island's industrial base is digitizing, and that creates demand for exactly the kind of engineering talent that has to live nearby.

You cannot build good process modeling for a biologics facility from four time zones away without understanding the facility. You cannot build computer vision inspection without standing at the line. As Puerto Rico's manufacturing and life sciences operations get more technically sophisticated, the software and data capability grows alongside them, and that growth is structural rather than fashionable.

That is a less exciting story than a startup scene. It is a considerably more durable one.