DevTools work wins on
tools other engineers depend on, with public adoption numbers
— not the tools you use at work.
DevTools and infrastructure builders are endorsed on the UK Global Talent visa's digital technology route via Tech Nation, the same body that assesses software engineers. This cohort is distinct in one decisive way: your product is developer tooling or infrastructure that other engineers adopt, so your evidence is unusually public and measurable — GitHub stars, package-registry download counts, dependent-project totals, named companies running your project in production. The applicants who clear the bar point at a tool, framework, library, or infrastructure project they authored or lead-maintain with verifiable adoption. The claim that sinks applications is confusing using a popular tool with building one: 'I use Kubernetes / Terraform / Docker daily' or 'I built our internal CI/CD' is not a contribution the panel can verify or that anyone outside your company depends on.
This page is about building the tools, platforms, and frameworks that get distributed and adopted — not about operating infrastructure and reliability day-to-day. If your work is running production systems, on-call, SRE, and platform operations, the sibling page for DevOps / SRE engineers is the closer fit; this one is for authors and maintainers of distributable developer tools. Exceptional Talent fits authors and lead-maintainers of tools used at scale with named production adopters — a CNCF / Apache Software Foundation / Linux Foundation project you maintain, a commercial dev-tool with paying customers you built, or an open-source project with six-figure download counts. Exceptional Promise fits senior builders (roughly 5–8 years) who are growing the footprint of a real, externally-adopted tool.
Last updated ·
For a DevTools / infrastructure engineer, the answer is usually clear.
For DevTools and infrastructure builders the route is Tech Nation under the digital technology pillar — this is industry engineering, not academic work, so there is a single route and the tier choice is the substantive decision. The defining failure mode for this role is confusing tool adoption with tool authorship. Running Kubernetes, writing Terraform, or building an internal CI/CD pipeline nobody outside your company can adopt is not evidence the panel rewards. What it rewards is authoring or lead-maintaining something external engineers depend on, with public adoption numbers to prove it — package-registry downloads, dependent-project counts, named companies in production, a graduated CNCF / Apache project. If your best material is internal-only, externalise and open-source it, or apply for Promise.
Tech Nation's digital technology route is purpose-built for industry developer-tooling and infrastructure engineering. There is no academic peer-review alternative for this cohort — building distributable tools is industry work, so Tech Nation is the route regardless of tier.
Which criteria DevTools / infrastructure builders actually win.
Innovation
DevTools and infrastructure builders win on innovation with a concrete, externally-adopted artefact: a framework, library, CLI, or infrastructure project you authored that solved a problem the ecosystem didn't have a good answer for, and that other engineers now build on. A new build tool with real downloads, a widely-used Kubernetes operator, a language server or compiler plugin adopted across editors, an authored RFC or design doc a major ecosystem accepted — these are innovation the panel can verify. 'I built internal tooling for my team' is innovation only if it was externalised and adopted outside your company; otherwise the panel has nothing to check.
Recognition
This is the criterion this cohort most often mis-evidences. The patterns that win: invited or accepted talks at KubeCon, DockerCon, QCon, Strange Loop, PlatformCon, or a language / ecosystem-specific conference (RustConf, GopherCon, PyCon, JSConf); maintainer or Technical Oversight Committee status on a CNCF / Apache Software Foundation / Linux Foundation project; being cited or depended-on across industry with named companies naming your tool in their engineering blogs or tech-radar entries. GitHub stars alone are not recognition — stars are cheap and don't prove production use. What proves recognition is downloads, dependent projects, named adopters, and third-party attestation you can point the panel at.
Significant contribution to UK digital economy
The mandatory criterion — every applicant must satisfy it. For DevTools and infrastructure builders this is usually evidenced by a coherent narrative across your other criteria plus your personal statement: 'I build developer infrastructure in Y sub-sector, here is the authored tool, its adoption numbers, and the named companies running it that confirm it'. The panel assesses this holistically — a single coherent story about the tooling or infrastructure you contribute to the ecosystem in a named UK digital sub-sector, not a list of the technologies you have used on the job.
Technical contribution to the digital technology sector
This is where open-source and infrastructure authorship pay off. Authorship or lead-maintainership of a widely-adopted developer tool, framework, or infrastructure project — verifiable in public commit history, OWNERS / MAINTAINERS files, and package registries — is strong evidence. CNCF / Apache Software Foundation / Linux Foundation project maintainership, especially on a graduated or incubating project, is gold-standard. Authored RFCs or design docs adopted by a major ecosystem, a commercial dev-tool with paying customers you built or led, and dependent-project counts across the ecosystem all count. Using a popular tool does not; authoring or lead-maintaining one that others depend on does.
The specific evidence the panel rewards.
- 01Authored / lead-maintained tool with verifiable adoption
A developer tool, framework, library, CLI, or infrastructure project you authored or lead-maintain, with verifiable adoption numbers: package-registry downloads (npm / PyPI / crates.io / Docker Hub pulls / Homebrew installs), dependent-project counts, GitHub stars alongside those downloads, and named companies running it in production. Gold-standard evidence for the technical-contribution and innovation criteria. Include the download figures, the dependent-project totals, and the named adopters — stars alone are not enough.
- 02CNCF / Apache / Linux Foundation project maintainership
Maintainer or Technical Oversight Committee status on a Cloud Native Computing Foundation, Apache Software Foundation, or Linux Foundation project — especially one at incubating or graduated status. Verifiable in public MAINTAINERS / OWNERS files and foundation governance records. Include your commit and review stats, the specific area you own, and the graduation status of the project.
- 03Commercial developer tool with paying customers
A commercial dev-tool, developer platform, or infrastructure product you built or led that has paying customers — verifiable via customer counts, revenue, or named enterprise adopters. Strong for the commercial-impact and technical-contribution criteria. Include the customer numbers, named accounts you can disclose, and your specific role in building it.
- 04Named-conference talks (KubeCon / DockerCon / QCon / PlatformCon)
Invited or accepted talks at KubeCon / CloudNativeCon, DockerCon, QCon, Strange Loop, PlatformCon, or a language / ecosystem-specific conference (RustConf, GopherCon, PyCon, JSConf). Accepted CFPs at named venues are verifiable recognition evidence. Include the conference, year, talk title, and the recording or programme link.
- 05Adopted RFCs / design docs in a major ecosystem
RFCs, design documents, or standards you authored that a major ecosystem accepted and shipped — a language RFC, a Kubernetes Enhancement Proposal (KEP), a widely-adopted specification. Verifiable in the ecosystem's public proposal repository. Include the proposal identifier, your authorship credit, and the implementations that follow it.
- 06Named production adopters and industry citations
Named companies running your tool in production, engineering-blog posts or tech-radar entries citing it, and dependent projects that build on it. Public, attributable evidence that external engineers depend on your work — among the strongest recognition evidence for this role. Include the named adopters, the citation links, and the dependent-project counts.
- 07Three independent recommendation letters
Three letters from senior figures who can speak to your work — ideally from projects and companies other than your current employer (a foundation TOC member, an engineer at a company that adopted your tool, a conference programme chair). Letters from your direct manager are weaker than letters from external adopters and maintainers in the ecosystem.
Common failure modes, and the fix.
FixUsing a tool is not contributing one. The panel rewards authoring or lead-maintaining something external engineers depend on. Reframe as 'I authored / lead-maintain [tool], with [download count] downloads and [named companies] running it in production', and provide the registry figures and the named adopters. Proficiency with a popular tool belongs in your CV, not as a criterion claim.
FixInternal-only tooling is not a contribution to the ecosystem — no third party depends on it and the panel can't verify its impact. If the work is strong, externalise and open-source it, publish the adoption numbers, and reframe around external dependents. If you can't, lead with a different artefact or apply for Promise on a tool that is externally adopted.
FixStars are cheap and don't prove production use. Replace the star count with verifiable adoption: package-registry downloads, dependent-project counts, and named companies running the project. If a repo has stars but no downloads or adopters, it isn't strong evidence — lead with a project that has real usage numbers.
FixA fork or a thin wrapper around an existing tool is not authorship, and a personal side-project with no adoption is not contribution. The panel rewards a tool you designed and lead that others depend on. Point at the original work you authored, its download and dependent-project numbers, and the named adopters — or drop the claim.
FixThe personal statement is your one chance to argue the holistic case for the mandatory criterion. Use it to articulate a single coherent narrative — what tool or infrastructure you authored, its verifiable adoption numbers, why it matters, and why it specifically benefits a named UK digital sub-sector. A technology inventory is not an argument.
The specifics that decide outcomes.
Concrete achievement and reference-letter templates (DevTools / infrastructure)
Reference letter from a downstream adopter or foundation maintainer: 'I have worked alongside [Engineer] on [Tool / project] since [Year]. They authored [specific component — e.g. the operator reconciliation loop / the plugin API], now depended on by [named companies / N dependent projects], with [download figure] downloads on [registry]. Their specific contribution was [precise work]. I'd place [Engineer] among the most influential builders of tooling in this area of the ecosystem.'
Quantified adoption narrative for the personal statement: 'As author and lead-maintainer of [Tool], I designed and built [specific component]. It has [download figure] downloads on [npm / PyPI / crates.io / Docker Hub], [N] dependent projects, and is run in production by [named companies]. It reached [CNCF incubating / graduated] status in [Year] and I presented it at [KubeCon / QCon] [Year] ([attendance figure]).'
Maintainer letter ask you can send to a foundation TOC member or downstream engineer: 'Hi [Name], I'm applying for the UK Global Talent visa under Tech Nation. The panel weights letters from collaborators and adopters outside my employer who can speak to a specific external contribution. Would you write a 1-page letter on my authorship / maintainership of [Tool] — what I specifically built, its adoption, and who runs it in production? I can share a short brief on what the panel's technical-contribution and recognition criteria look for.'
Innovation-criterion narrative example: 'Authored [Tool / framework / RFC] ([Year]). It introduced [specific capability the ecosystem lacked], now with [download figure] downloads, [N] dependent projects, and adoption by [named companies]. Maintained through [N] releases; the design was accepted as [RFC / KEP / spec] by [ecosystem].'
Recognition narrative example: 'Accepted talk at KubeCon / QCon [Year] ([attendance]). Maintainer / TOC member on [CNCF / Apache project] since [Year]. [Tool] cited in [named company] engineering blog and [tech-radar] entry; [download figure] downloads across [N] dependent projects.'
What 'externally-verifiable' actually looks like for DevTools / infrastructure builders
Tech Nation's guidance distinguishes internal or self-asserted achievement (I built our internal platform, I use these tools, my repo has stars) from externally-verifiable contribution (a tool others download and depend on, attested by companies and maintainers outside your employer). For this cohort the footprint is unusually measurable — downloads, dependent projects, and adopters are all public — so the panel can and does check. The applicants who clear the bar lead with the numbers that survive that check.
External verifiability here means: (a) artefacts others run or depend on — a tool with real downloads, a maintained CNCF / Apache project, a library with dependent-project counts; (b) third-party attestation — accepted CFPs at named conferences, foundation maintainer status, named companies citing your tool; (c) a verifiable footprint — package-registry download figures (npm / PyPI / crates.io / Docker Hub / Homebrew), dependent-project totals, and public MAINTAINERS / OWNERS files.
'Authored / maintained tool with verifiable downloads and named production adopters' is the canonical strong pattern for this role. The panel rewards: tool name + download figure + named companies in production + your specific authored component (not just 'I contributed') + the registry and dependent-project evidence. Public examples of the kind of work that lands: CNCF projects (Prometheus, Envoy, Argo, Cilium), build and package tooling (Bazel, Nx, pnpm, uv), and infrastructure frameworks with wide adoption.
Foundation maintainership and paid adoption are gold-standard and verifiable by definition. Maintainer or TOC status on a graduated CNCF / Apache project, or a commercial dev-tool with named paying customers, reads as contribution and commercial impact the panel can confirm in public governance records and customer references — lead with it if you have it.
Common evidence patterns for senior DevTools and infrastructure builders
Pattern 1 — foundation-project maintainer: maintainer or TOC status on a CNCF / Apache / Linux Foundation project at incubating or graduated status, with named companies running it. Pair with a KubeCon / QCon talk + a letter from a foundation peer or downstream team. The strongest single pattern; often supports a Talent application on its own.
Pattern 2 — open-source tool author with real adoption: a framework, library, or CLI you authored with six-figure download counts, dependent projects, and named adopters + a conference talk on the design. Strong for both tiers; the download and dependent-project numbers are the verifiable core.
Pattern 3 — commercial dev-tool builder: a developer tool or platform you built or led with paying customers and named enterprise adopters + case studies or engineering-blog citations. Strong for the commercial-impact criterion; the customer counts and revenue are the verifiable core.
Pattern 4 — ecosystem standards author: authored RFCs, KEPs, or specifications a major ecosystem accepted and shipped, with implementations following them + a talk at the ecosystem's flagship conference. Verifiable in the public proposal repository.
Pattern 5 — infrastructure framework maintainer: lead-maintainer of a widely-used infrastructure framework, operator, or platform component (a Kubernetes operator, a Terraform provider, a language server) with verifiable installs and named adopters. Verifiable in public registries and repositories.
Common rejection patterns and how to fix them
Rejection 1 — 'I use Kubernetes / Terraform / Docker daily' framed as contribution. Fix: using a tool is not contributing one. Reframe as authored / lead-maintained [tool] with [download count] downloads and [named companies] in production, with the registry figures and named adopters as evidence.
Rejection 2 — 'I built our internal CI/CD / platform' nobody outside your company can adopt. Fix: internal-only tooling isn't a contribution to the ecosystem. Externalise and open-source it, publish the adoption numbers, and reframe around external dependents — or lead with a different artefact.
Rejection 3 — raw GitHub stars with no downloads or named adopters. Fix: stars are cheap and don't prove production use. Replace with package-registry downloads, dependent-project counts, and named companies running the tool.
Rejection 4 — a forked or thin-wrapper project claimed as authorship, or a side-project with no users. Fix: a fork isn't authorship and an unadopted side-project isn't contribution. Point at original work you authored, its download and dependent-project numbers, and named adopters.
Rejection 5 — personal statement that inventories the technologies you've used. Fix: argue the holistic mandatory case instead — what tool or infrastructure you authored, its verifiable adoption numbers, the artefact that confirms them, and why it benefits a named UK digital sub-sector (fintech, cloud infrastructure, developer platforms, AI tooling).
Career path on the visa — what changes day one
Day one of Global Talent grant: you can work for any UK employer, multiple employers simultaneously, your own UK or non-UK company, contract, freelance, or advise. There's no SOC code, no salary floor (vs Skilled Worker), no employer-tied amendment process — useful for tool authors who maintain a widely-adopted open-source project alongside a main role.
Compensation context: senior DevTools, platform, and infrastructure-engineering salaries at established UK and remote-UK firms run roughly £100–190k for senior ICs, with staff / principal and head-of-platform roles reaching £220k+ base. Authors of widely-adopted open-source tooling frequently command a premium and have sponsorship, consulting, or open-core commercial income on top of a salaried base.
Founder optionality: Global Talent permits founding companies — relevant for engineers building developer-tooling, infrastructure, or open-core startups. The SEIS / EIS investor-incentive schemes are structurally favourable to early-stage equity, and the UK has a growing developer-tools and cloud-infrastructure VC base. This page is not legal advice; take company-formation and tax advice separately.
ILR clock: 3 years for Talent, 5 years for Promise. Time spent outside the UK over 180 days in any rolling 12-month period can break the clock — track it meticulously, especially if you travel for conferences or a globally-distributed maintainer team. After ILR the route's conditions fall away; British citizenship is reachable 12 months after ILR.
From today to the visa decision.
- 01Pre-application: triage your evidence
Use the Rate-my-application grader. Decide tier (Talent vs Promise). Identify three referees — at least two outside your current employer (a foundation TOC member, an engineer at a company that adopted your tool, a programme chair).
- 02Week 0-2: Stage 1 endorsement application
Submit endorsement online via Tech Nation portal. PDF evidence + statements of personal achievement and contribution. £561 fee.
- 03Week 5-8: Endorsement decision
Tech Nation: 8 weeks standard, 3 weeks fast-track (+£500). Decision via email; endorsement letter uploaded to your account.
- 04Week 8-10: Stage 2 visa application + biometrics
File at gov.uk within 3 months of endorsement. £205 visa + IHS (£1,035/yr per adult). Biometrics at local UK VAC.
- 05Week 10-13: Visa decision
Standard 3 weeks. Priority 5 working days (+£500). Super-priority next-day (+£1,000).
- 06Week 13-16: UK arrival + onboarding
Collect Biometric Residence Permit within 10 days. Register with a GP, get NI number, open UK bank account. Start applying for roles or continue maintaining a widely-adopted project.
- 07Year 3 or 5: ILR
Apply for Indefinite Leave to Remain. Life in the UK test, English language proof. Citizenship eligible 12 months later.
Practical tips for this role.
Lead with 'authored / lead-maintain [tool], run by [named companies] with [verifiable downloads]' — that framing addresses the technical-contribution and recognition criteria directly.
Apply for Promise if your evidence is a real, externally-adopted tool with a growing footprint — the bar is lower and aligned with senior IC profiles.
Use KubeCon, DockerCon, QCon, Strange Loop, or PlatformCon for recognition, plus named-company citations and tech-radar entries.
Show verifiable adoption: package-registry downloads (npm / PyPI / crates.io / Docker Hub / Homebrew), dependent-project counts, named production adopters.
Externalise and open-source strong internal tooling before applying — publish the adoption numbers so the panel can verify them.
Highlight CNCF / Apache / Linux Foundation maintainership — foundation TOC status, especially on a graduated project, is gold-standard.
Tie your tooling or infrastructure impact to a named UK digital sub-sector (fintech, cloud infrastructure, developer platforms, AI tooling) for the mandatory criterion.
Don't list the technologies you've used on the job — using Kubernetes / Terraform / Docker is not contributing a tool to the ecosystem.
Don't apply for Talent on internal-only tooling or a starred-but-unused repo — rejected Talent applications don't auto-roll-down to Promise; you'd reapply from scratch.
Don't lean on GitHub stars as recognition — stars are cheap and don't prove production use.
Don't submit a side-project tool with no users or a thin wrapper claimed as authorship — the panel can't verify impact and nobody depends on it.
Don't rely on internal CI/CD or a private platform nobody outside your company can adopt — unverifiable internal work carries no weight.
Don't undersell a commercial dev-tool with paying customers — if you built one, lead with the customer counts and named enterprise adopters.
Don't recite your CV in the personal statement — the panel reads the CV separately.
Verify at the source.
Authoritative UK Home Office landing page.
Endorsing body for digital technology — the route for DevTools / infrastructure builders.
Official Tech Nation application guide — required reading before applying.
What the Tech Nation 10-year report shows about who actually gets endorsed — internal site research.
Step-by-step practitioner's guide for the Tech Nation route.
Maintainer or TOC status on a CNCF project — especially graduated / incubating — is gold-standard technical-contribution evidence.
Public package-registry download counts — verifiable adoption evidence for JavaScript / Node tooling authors.
The Rust package registry — download and dependent-crate counts are verifiable adoption evidence for Rust tooling authors.
Public commit history, dependent-project graphs, and MAINTAINERS files — where the panel verifies authorship and adoption.
The flagship cloud-native conference — accepted talks here are decisive recognition evidence for infrastructure builders.
One-click LinkedIn search to find DevTools / infrastructure builders who hold the UK Global Talent Visa — useful for peer references and benchmarking.
Common questions.
Do I need a UK job offer before applying?+
No. Global Talent is self-petition — there's no requirement for a UK employer, sponsor, or job offer at any stage. Once endorsed and granted the visa, you can work for any UK employer, multiple employers, your own company, or self-employ. Many endorsed tool authors and infrastructure builders arrive without a UK role lined up and find one — or keep maintaining a widely-adopted open-source project — in their first weeks.
Which tier should a DevTools or infrastructure builder apply for?+
Talent ('Exceptional Talent') fits authors and lead-maintainers of tools used at scale with named production adopters — a CNCF / Apache / Linux Foundation project you maintain, a commercial dev-tool with paying customers, or an open-source project with verifiable six-figure download counts. It leads to ILR in 3 years. Promise ('Exceptional Promise') fits senior builders under roughly 5–8 years who are growing the footprint of a real, externally-adopted tool. It leads to ILR in 5 years. Applying for Talent on internal-only tooling or a starred-but-unused repo is the most common refusal pattern.
I built internal tooling / CI/CD for my company — is that good evidence?+
Only if it was externalised and adopted outside your company. Internal-only tooling is not a contribution the panel can verify — no third party depends on it and there are no public adoption numbers. If the work is strong, open-source it, publish the download and dependent-project counts, and frame the claim around external adopters. A deployed-but-private platform nobody else can run won't clear the bar.
Do GitHub stars count as evidence?+
Not on their own. Stars are cheap and don't prove production use — a repo can have thousands of stars and near-zero real adoption. What counts is verifiable adoption: package-registry downloads (npm / PyPI / crates.io / Docker Hub pulls / Homebrew installs), dependent-project counts, and named companies running the tool. Lead with the download and adopter numbers; treat stars as a secondary signal, not the headline.
What counts as a 'contribution' to a developer tool or infrastructure project?+
Authorship or lead-maintainership — verifiable in public commit history and MAINTAINERS / OWNERS files — of a tool, framework, library, or infrastructure project that others depend on, with adoption numbers to prove it. Maintainer or TOC status on a CNCF / Apache / Linux Foundation project is gold-standard, especially at incubating or graduated status. Using the tool does not count; authoring or lead-maintaining one others build on does.
How is this different from the DevOps / SRE engineer page?+
This page is for people who build the tools, platforms, and frameworks that get distributed and adopted — authors and lead-maintainers of developer infrastructure. The DevOps / SRE page is for people who operate production infrastructure and reliability day-to-day: on-call, platform operations, incident response. If your evidence is a widely-downloaded tool with named adopters, this page is the fit; if it's running and scaling production systems, see the DevOps / SRE page. The Tech Nation route is the same; the winning evidence differs.
Do conference talks count as recognition?+
Yes — accepted CFPs at named venues are among the strongest recognition evidence for this role, because they're public and attributable. Invited or accepted talks at KubeCon / CloudNativeCon, DockerCon, QCon, Strange Loop, PlatformCon, or a language / ecosystem conference (RustConf, GopherCon, PyCon, JSConf) clear the recognition criterion. Include the conference, year, talk title, and the recording or programme link.
Does a commercial dev-tool with paying customers help?+
Yes — a commercial developer tool, platform, or infrastructure product you built or led with paying customers is strong evidence for the commercial-impact and technical-contribution criteria. Show verifiable customer counts, revenue, or named enterprise adopters, and be specific about your role in building it. Paid adoption is exactly the kind of external, verifiable footprint the panel rewards.
Will my US H-1B / O-1 / L-1 status affect the UK application?+
No. Your current US visa status has no bearing on the UK endorsement or visa. Many Tech Nation-endorsed engineers apply from the US while still on H-1B; some keep both options open during the transition.
What's the typical end-to-end timeline?+
Tech Nation 8 weeks standard (3 weeks fast-track for +£500). Stage 2 visa 3 weeks standard, 5-day priority. End-to-end under 4 months is typical.
Related pages
The parent role page — same Tech Nation route, generic-SWE evidence patterns.
The sibling route — that page is operating infrastructure and reliability; this one is building the distributable tools.
The full step-by-step practitioner's guide for the Tech Nation route.
What the 10-year report shows about who actually gets endorsed.
If you have a UK job offer in hand, here's the trade.
Free AI grader against the four Tech Nation criteria.