Separate legal structure from evidence quality.
If the live question is petitioner, job offer, status, timing, consultation, or itinerary, use counsel. If the live question is how the engineering record maps to O-1A criteria, build the proof table first.
Use this first if you need to sort original contribution, critical role, judging, authorship, and legal-structure questions.
Free Packet map O1A KitUse this when the evidence exists but needs field definition, criteria ranking, exhibit order, and counsel handoff.
$99 EB1A fit Profile Builder ProUse this if the same engineering evidence needs an EB1A readiness test before you spend on a full filing stack.
$99Patents are one kind of proof, not the whole case
Software engineers often get stuck on the wrong question: "Do I need a patent?" A better first question is: "Which O-1A criteria can I prove with independent evidence?"
The O-1A regulation for science, education, business, and athletics lists multiple evidence types. It includes original contributions, authorship, critical or essential role, high salary or remuneration, judging, awards, memberships, and published material about the person. Patents may support an original-contribution story, but the regulation does not make patents the only route.
What can replace a patent in a software engineering record?
Replace the patent question with a proof question. What shows that qualified people outside your immediate job description relied on your work?
| O-1A bucket | Software-engineering proof that can work | Weak version |
|---|---|---|
| Original contribution | Open-source adoption, downstream integrations, cited technical work, production system impact, external users, or expert letters tied to verifiable artifacts. | "I built an internal system" with no outside reliance or field significance. |
| Critical or essential role | A defined role on a distinguished product, research project, infrastructure system, or company initiative where your specific work changed the outcome. | A senior title without proof of responsibility, project importance, or dependency on your work. |
| Judging | Program committee work, conference review, grant or paper review, technical competition judging, hackathon judging, or senior-level code/architecture review selected because of expertise. | Routine internal code review treated like independent judging. |
| Authorship | Scholarly articles, technical papers, major engineering blog posts, standards work, or public technical writing that field readers actually use. | Generic blog posts that do not connect to the claimed field. |
| High salary or remuneration | Contracts, compensation letters, equity or bonus records, and credible market comparisons for the same field and geography. | A salary number with no comparator or reliable evidence. |
The strongest engineer cases are not resume summaries
O-1A evidence gets weaker when it reads like a promotion packet. The officer should not have to guess why the work mattered beyond one employer.
For each strong project, write one row:
- What was the narrow field?
- What problem did the system, model, architecture, dataset, or research solve?
- Who used it outside your own task list?
- What proof shows reliance, adoption, recognition, or selection?
- Which O-1A criterion does that proof support?
If a row cannot name outside reliance or independent recognition, it may still be useful background, but it should not carry the case.
If you only have internal work
Internal work can still matter, especially when the organization or project has a distinguished reputation and your role was truly critical. The record needs context. Show why the organization, platform, team, system, or project mattered, and what changed because of your work.
Be careful with confidential evidence. Do not upload sensitive employer materials into public tools. Create redacted summaries, public artifact lists, and counsel-safe exhibit descriptions.
When the answer is "wait and build"
Some engineers have promising facts but not enough proof yet. If there is no urgent status deadline, a short build window can be better than a rushed packet.
- Turn informal open-source usage into maintainers, stars, forks, package downloads, integrations, and user quotes.
- Convert internal impact into allowed, redacted letters and project descriptions.
- Find judging roles that are genuinely expertise-based.
- Publish technical work that supports the same field story.
- Collect compensation evidence with market comparisons.
Bottom line
No patents does not automatically kill an O-1A software engineering case. It does make evidence discipline more important. The useful work is to map criteria, prove outside reliance, separate ordinary job responsibility from field recognition, and use counsel for petitioner and filing-structure questions.
Start with the free O1A evidence bucket map. If the map shows real proof but the packet is scattered, use the ChatEB1 O1A Kit.