# Verifying the Real Team Behind a Dev Shop Before You Sign

*You can take one agency proposal and confirm or disprove, from public evidence alone, that its named engineers are real, employed there, and did the work shown.*

- Canonical URL: https://www.refolk.ai/guides/verify-dev-shop-real-team
- Pillar: Engineering and open source
- Format: Teardown
- Published: 2026-08-16
- Last reviewed: 2026-08-16
- Reading time: 17 min

Before you commit a build budget to an outsourced agency, you need to know that the senior engineers in the pitch deck are real people, that they actually work at the firm, and that they are the ones who will write your code. This guide is for founders, engineering managers, and technical buyers evaluating a dev shop. It carries one proposal all the way through independent verification you can do from public evidence, before spending a cent, so you catch a bait-and-switch before signing rather than during the trial.

Most vetting advice stops at "ask them who codes, then run a paid trial." That trusts the vendor's own answers. This guide does the opposite: it matches each pitched name to public profiles, commit history, and company records, shows the real queries and intermediate counts, and names the wrong turns that let a rotating or subcontracted team hide.

## What the proposal is actually claiming, and what you can verify

A dev shop proposal makes three claims stacked together: these named engineers exist, they work here, and they did the work we are showing you. Each claim has a different public source, and no single source proves all three.

The proposal I will carry through this guide names four engineers: a lead backend engineer, two senior engineers, and a staff-level architect, each attached to two case-study repositories the agency says it built. Your first job is to turn the deck into a claim set you can check row by row. Nothing gets verified until it is written down as a discrete, falsifiable statement.

| Claim in the deck | Public source that speaks to it | What that source cannot prove |
|---|---|---|
| The engineer exists | Professional profile, GitHub account | That they work at the agency |
| They work at the agency | Registry officers, org membership, verified email | That they will write your code |
| They did the cited work | Commit history, Blame, Verified badge | That authorship was not forged |

Read the right-hand column as the load-bearing part. Employment is self-asserted on a profile. Registries list directors, not rank-and-file engineers. Commit authorship ties a name to code but is trivially forgeable. The method below is about stacking weak sources until the picture holds, and refusing to let any one of them carry the whole verdict.

> **Rule:** No single source proves "will write your code"
>
> Public evidence can establish that an engineer exists and is plausibly affiliated with the agency. It cannot prove who will be assigned to your build. That claim is only secured in the contract, not in the research.

## The four public sources and what each one fails to prove

Four independent public sources confirm employment, and each fails in a specific way you must know before you weight it. Stack them; never lean on one.

**Company registry.** National registries and aggregators give incorporation date, status, and officers. An aggregator draws a single unified set of records from over 140 government registries and other official sources. The failure: registrars do not check the accuracy of what is filed, and registries list officers and directors, not engineers. An "active" status proves the entity exists and nothing about staffing.

**Professional profiles.** These confirm a claimed employer and tenure. The failure: every field is self-asserted. A profile listing the agency as current employer is a claim, not corroboration.

**Commit history.** This ties a named person to specific code through authorship and Blame. The failure is severe enough to have its own section below: anyone can commit under another person's identity because Git allows changing the author email in the configuration.

**Org membership.** Public members of the agency's GitHub org link a person to the company. The failure: membership can be hidden, and it can be granted to subcontractors who are not staff.

#### The verification stack, weakest claim outermost

1. **Registry record** - the legal entity exists and has an active status
2. **Professional profile** - a person claims this employer and tenure
3. **Org membership** - a person is publicly linked to the agency
4. **Verified commit** - a cryptographically signed identity touched the code
5. **Contract SOW** - the named engineers are assigned to your build

*Each layer narrows what is proven; only the contract secures who writes your code.*

## Why commit authorship lies, and how the Verified badge fixes it

Commit authorship is the weakest link precisely because it looks strongest. Founders trust names on commits, yet the name and email on a commit are user-set fields that anyone can change. A commit that says "Senior Architect" wrote it proves nothing about who ran the command.

The counter-check is the cryptographic signature. GitHub marks a commit or tag "Verified" if it is signed with a GPG, SSH, or S/MIME key that was successfully verified. That badge is the only commit signal worth real weight, because it binds the commit to a key the author controls rather than to a string they typed. The catch, which you should expect going in, is that most agency repos are not signed. Absence of the badge is not proof of fraud; presence of it on load-bearing commits is strong corroboration.

Two forgery patterns show up when you look closely at a thin profile. The first is the manufactured graph. GitHub's contribution graph only cares about commit timestamps, not content, so a "forest" of green squares can be generated by tools built for exactly that purpose, with no substantive repositories behind it. The second is the purchased account: sellers offer profiles stacked with contributions to popular repos, long commit histories, and green-square gardens, priced upwards of $5,000. This inverts the meaning of a dense graph. On a profile with no real projects, heavy green is a negative signal.

**$5,000+ - Price of an achievement-loaded GitHub account**

Fake profiles ship with long histories and dense green squares, so read a graph on a thin profile as a warning, not a credential.

The scale of the underlying reputation market is not small. One academic study of GitHub event data identified six million suspicious stars, which tells you that reputation-as-a-service is an industry, not a fringe trick. Treat any signal that can be bought as untrustworthy until you find the substance beneath it.

> A dense green graph on a thin profile is a purchased good, so it counts against the profile, not for it.

## Reading the roster against market depth

The market an agency staffs from changes how a fabricated roster behaves under scrutiny. A thin talent market makes bait-and-switch self-defeating; a deep one makes it easier to hide. Refolk's index quantifies the gap.

| Market | Matching SWE / Senior SWE profiles | Relative depth |
|---|---|---|
| India (IT & Services) | 34,041 | 1x |
| Ukraine (IT & Services) | 313 | 108.8x smaller |

In Refolk's index of professional profiles, a query for Software Engineer and Senior Software Engineer in IT and Services returns 34,041 profiles in India against 313 in Ukraine, a 108.8x difference derived from those counts. The practical read: a firm claiming a deep India bench sits in a pool so large you cannot enumerate it, so you verify names one at a time. A firm claiming the same in a thin market can nearly be exhausted, so fabricated names fail fast against the visible bench.

Employer concentration is the second lever. When public profiles cluster in one firm, a roster is easy to cross-match; when they disperse, you are forced into name-by-name checking.

| Market | Top employer share of 25-profile sample | Interpretation |
|---|---|---|
| India | 17 of 25 (68%) | high concentration in one firm |
| Ukraine | 3 of 25 (12%) | dispersed across many firms |

In Refolk's index, a 25-profile sample in India showed the single most common employer holding 17 profiles, a 68% share, while the Ukraine sample dispersed across many firms at 12%. High concentration is a gift to a verifier: the pitched engineers should show up in the same public cluster as their claimed employer. When they do not, that is a discrepancy worth a hard question.

I ran this search: `Senior backend engineers who list an outsourcing agency as their current employer and have public GitHub accounts` - [see the full result list](https://www.refolk.ai/s/zhv7cmsexf).

*Returns people who publicly attach themselves to the firm, so you can cross-match the pitched roster against who actually claims to work there.*

This is the friction [Refolk](/) removes. Matching a deck of names against who publicly claims a given employer, in plain English, is the tedious middle of the job. Asking for the people rather than clicking through profile after profile is where the hours go back into your evaluation.

## Turnover and tenure: what a rotating roster looks like

There is no published threshold that defines a bait-and-switch roster precisely. What you have are baselines, and the discipline to use them as context rather than as a verdict. Short tenure is normal in this field; the signal to weight is a pitched senior with no visible history at the firm at all.

| Metric | Value | Source |
|---|---|---|
| SWE annual turnover | 23 to 25% | devsu.com |
| Developers with under 2 years tenure | 69% | invene.com |
| European engineering average tenure | 2 years 11 months | ravio.com |
| Broad tech attrition | around 13.2% | bucketlistrewards.com |

Software engineering is among the top three roles with the highest turnover worldwide, averaging 23 to 25% annually, nearly double the cross-industry median of about 13.2%. One analysis of roughly 103,000 developers found 45% have one to two years of tenure and 69% under two years, and European engineering tenure sits around two years eleven months.

High baseline churn is exactly what gives a rotating shop cover. With 69% of developers under two years, an agency can explain away short tenures as ordinary, and it would be right to. So tenure alone never proves rotation. Pair it with commit-identity evidence: a roster where the pitched seniors have no visible history at the firm, no verified commits to the cited repos, and no public org membership is below even the high-churn norm in a way that short tenure never is.

> **Watch out:** Do not read short tenure as fraud
>
> With most developers under two years at their employer, short tenure is the industry baseline, not a red flag. The disqualifying pattern is a pitched senior with no traceable history at the agency, not one who joined recently.

## The verification procedure, step by step

Run these eight steps in order on one proposal. The whole pass takes most of a working day and costs nothing but your time. Each step ends with a concrete "done" condition so you know when to move on.

#### Verify one dev shop's roster before signing

1. **Extract the claim set from the proposal** - Build a table of every named engineer, their claimed role, seniority, and the case-study repos or products cited. Done when each pitched name has a row you can verify against.
2. **Confirm the legal entity** - Look up the agency in the national registry or an aggregator for incorporation date, status, and officers. Done when you have a company number and active status, noting registry data is unverified by the registrar.
3. **Match each name to a professional profile** - Confirm the current-employer field and tenure against the pitch for every pitched name. Done when each name resolves to one profile listing the agency, with any missing or mismatched name flagged.
4. **Map names to the GitHub org** - Check public org membership and pinned repos for the agency. Done when you know which pitched engineers are visible org members versus invisible.
5. **Audit the cited work's commit history** - In each cited repo read commit authors, Blame, and the Verified badge. Done when you can state per repo whether a pitched name authored substantive commits under a verifiable identity.
6. **Run the fraud counter-checks** - For any suspiciously perfect profile check repo substance, external traces, and signed-commit status. Done when green-square-only or purchased-looking profiles are flagged.
7. **Corroborate low-footprint engineers off-platform** - Use uncontrolled references, talks, packages, and officer records for anyone with a thin public trail. Done when each low-footprint name has one independent corroboration or is marked unconfirmed but not disproven.
8. **Decide and lock the roster contractually** - Write the confirmed named engineers into the statement of work and assign IP to you. Done when the pitched seniors are named in the SOW, not just the sales deck.

On order, practitioner guides and business guides disagree, and the disagreement is instructive. Some say to check GitHub before the first call: do your homework, check their GitHub, before you ever speak to sales. Business-oriented guides put references and registry last. Both camps agree a paid trial is the final confirmation. My preference is to confirm the entity and the profiles first, because those cheap checks tell you whether the deeper commit audit is even worth your afternoon.

### The wrong turn worth showing

On the carried example, step three returned three of four names cleanly, each listing the agency as current employer. The fourth name returned nothing. My first instinct was to flag it as fabricated. That was the wrong turn. Step seven corrected it: the fourth engineer had a conference talk and a maintained package under a personal handle, and a registry record listed a matching officer name at a related entity. The engineer was real, senior, and simply low-footprint on the platforms I checked first. Absence of public code lowers confidence; it does not condemn.

## How this goes wrong: failure modes and false positives

The most valuable part of any verification standard is the catalogue of ways it misfires. Each entry below is a way a competent buyer reaches a wrong conclusion, in both directions.

**Empty contribution graph read as fraud.** The false positive. A real senior with private or org-account work looks inactive, because if a company uses a separate org account those contributions never show on the personal profile, and GitHub only counts commits that land on the default branch, so feature-branch work is invisible until merged. Corroborate off-platform before disqualifying.

**Green squares trusted as skill.** The graph can be manufactured with fabricated-graph tools and cares only about timestamps, not content. Check repo substance and Verified badges, never the grid.

**Commit author trusted as identity.** Anyone can set another person's name and email as author. Require the Verified signature badge on the commits that matter, not the author string.

**Registry "active" read as team proof.** Registries list officers, not engineers, and do not verify filings. Never infer staffing from an incorporation record.

**Profile "current employer" trusted blindly.** It is self-asserted. Corroborate with org membership or verified commits from an agency domain.

**Curated references passed off as validation.** The references the agency controls tell you what they want you to hear; the ones they do not control tell you the truth. Find uncontrolled clients. A practical route: search for engineering leaders at the agency's past clients and message them directly, outside the reference list you were handed.

**Proxy performer on the call.** A developer performs well on video, then the trial code quality is dramatically different. Have the pitched engineer walk their own past commits live, so the person on the call is demonstrably the person behind the work.

#### Public footprint versus verified identity

Horizontal axis runs from Thin public footprint to Rich public footprint. Vertical axis runs from Identity unconfirmed to Identity verified.

| Quadrant | What it means |
| --- | --- |
| Thin and unconfirmed | Corroborate off-platform or mark unconfirmed but not disproven |
| Rich and unconfirmed | Suspect a purchased or borrowed profile; check repo substance and signatures |
| Thin and verified | Low visibility, real person; accept with off-platform corroboration |
| Rich and verified | Strong confirmation; the pitched claim holds |

*Read a pitched engineer on how much public trace exists against how well their identity is confirmed.*

The rich-and-unconfirmed quadrant is the trap. A profile with dense activity and no verifiable identity is where a purchased account lives. A thin-and-verified profile, counterintuitively, is safer: a real senior whose few public commits carry the Verified badge is exactly the person the deck claims.

## In-house build or quiet subcontract

No single public signal proves whether a build will be done in-house or quietly subcontracted; this is an inferential read from several traces. That said, the traces cluster in recognisable ways, and the risk is real. Clients report discovering that their agency outsourced the entire project overseas after signing.

Signals of a genuine in-house build:

- The pitched engineers appear as public members of the agency's GitHub org.
- They commit under verified emails on the agency's own domain.
- They leave external traces, because real projects leave traces outside GitHub.

Signals of hidden subcontracting:

- The delivered repo's authors are accounts unconnected to any pitched name.
- Those authors use generic or personal emails rather than the agency domain.
- Author geography clusters in a different region than the agency claims to staff from.

Cross-reference commit-author geography and profiles against the pitched roster. If the people writing the code are not the people in the deck, and they sit in a market the agency never mentioned, you are looking at subcontracting the pitch did not disclose. Sham-contracting is not merely a commercial risk; documented cases carry legal penalties, such as a firm fined over AUD 50,000 for false or misleading representations after outsourcing employees to a labour-hire company.

## Before you call the job done

Run this list against your completed pass. Every item is a checkable statement, not a topic. If any fails, you are not done.

#### Roster verification sign-off

- [ ] Every pitched engineer has a row in the claim set with role, seniority, and cited repos.
- [ ] The agency resolves to a company number with an active registry status.
- [ ] Each pitched name resolves to one professional profile listing the agency, or is flagged.
- [ ] You know which pitched engineers are public members of the agency GitHub org.
- [ ] For each cited repo you can state whether a pitched name authored substantive commits.
- [ ] Load-bearing commits from pitched seniors carry the Verified signature badge, or the absence is noted.
- [ ] Any dense-graph, thin-substance profile has been checked for purchase or fabrication.
- [ ] Each low-footprint engineer has one off-platform corroboration or is marked unconfirmed but not disproven.
- [ ] At least one uncontrolled reference, not from the agency's list, has been contacted.
- [ ] The confirmed named engineers are written into the SOW with IP assigned to you.

> **Tip:** Make the last step cash the first seven
>
> The paperwork step is where verification pays off. Confirm the registered company, how long it has operated, that the engineers are real and meetable, and that the contract assigns IP to you. Named engineers in the SOW is the only thing that survives the ink.

## Keeping the verdict current

A roster verified today is a roster verified today. Turnover in this field runs 23 to 25% a year, so a team confirmed at signing can rotate through the life of a build. Two mechanisms keep your verdict honest without a full re-audit.

First, re-check org membership and commit authors at each milestone. If the engineers landing commits on your deliverable stop matching the SOW names, you have caught rotation in flight, and the contract gives you the standing to raise it. Second, watch outflow. A query for people who left the agency in the last twelve months, checked against your named roster, tells you whether the specific engineers you locked in are still there. When one of them departs mid-build, you want to know from public traces before the agency tells you, not after.

The evidence here has a fixed shape: registries prove the entity, profiles and org membership prove affiliation, verified commits prove authorship, and only the contract proves assignment. When the market is thin, exhaustion does your work for you. When it is deep, you verify name by name. Either way, the discipline is the same. Do not let a forgeable field carry a verdict, and do not sign until the people in the deck are the people in the SOW.

## Frequently asked questions

### How do I check an agency's GitHub before hiring them?

Start with the agency's GitHub org and its public members, then open the specific repos their proposal cited. Read commit authors and Blame to see who touched the code, and check the Verified badge on load-bearing commits, since author names alone are forgeable. Cross-match the org members against the pitched roster: a pitched senior who is not a visible member and has no verified commits is a name to question.

### Can commit history prove a specific engineer wrote the code?

Not on its own. Git lets anyone set another person's name and email as the commit author, so a name on a commit is a claim, not proof. The only commit field worth weighting is the cryptographic Verified badge, which marks commits signed with a GPG, SSH, or S/MIME key. Most agency repos are unsigned, so pair authorship with profile, org membership, and a live walkthrough of the commits.

### Is an empty GitHub profile a red flag for a senior engineer?

No. Real seniors often show empty graphs because their work lives in private org accounts or on feature branches that have not merged to the default branch, and neither shows on a personal profile. Treat absence of public code as lower confidence, not disproof. Corroborate through registry records, profile tenure, uncontrolled references, and a live technical walkthrough before disqualifying anyone.

### What tenure counts as a rotating or bait-and-switch roster?

There is no published threshold for a bait-and-switch roster. Use benchmarks as context: software engineering turnover averages 23 to 25% annually and 69% of developers have under two years tenure, so short tenures are normal industry-wide. The signal to weight is pitched seniors with no visible history at the firm, not short tenure by itself. Tenure never proves fraud alone; it must pair with commit-identity evidence.

### How can I tell if an agency will secretly subcontract my project?

No single public signal is definitive; this is inferential. Look for the delivered repo's authors being accounts unconnected to any pitched name, using generic or personal emails, or clustering in a different geography than the agency claims. Signals of a genuine in-house build are pitched engineers appearing as public org members, committing under verified agency-domain emails, and leaving external traces. Cross-reference commit-author geography against the roster.

### What should the contract say to lock in the team I was pitched?

Write the confirmed named engineers into the statement of work rather than accepting a generic staffing clause. Confirm the registered company and how long it has operated, that the engineers are real and meetable, and that the contract assigns IP to you. This paperwork step is where the verification you did is cashed in; without named engineers in the SOW, nothing stops a swap after signing.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/verify-dev-shop-real-team*