The Outsourced-Build Partner Standard: Cleared, Conditional, or Walk Away

Deciding whether to sign with a software agency is a staffing decision wearing a procurement costume. This standard is for engineering managers, technical founders, developer-relations leads and technical sourcers who need to grade a build partner and the specific engineers it names against fixed, evidence-backed criteria. It gives you a rubric that returns Cleared, Conditional, or Walk Away, graded so a second reviewer reaches the same verdict from the same evidence.

Most vetting guides you will find are written by agencies and end with "run this on us too." They stop at the questions you ask the vendor. This one grades the answers against public evidence: the named engineers' real contribution history, the firm's own repos, references you did not let the vendor pick, and IP terms on the page. It treats the firm and its assigned people as one linked object, which is the only way to catch the name-on-the-pitch, junior-on-the-build swap.

What "Cleared" means and why the firm and its engineers are one object

Cleared means every load-bearing criterion passed against public evidence, not against the sales call: the entity is real, the named engineers' contributions are corroborated by verified signatures, references confirm the roster, the IP terms transfer ownership in writing, and a paid trial was delivered by those same names. Grade the company and the assigned people as a single linked object, because a firm's reputation does not write your code and a strong engineer you never get assigned does not either.

The reason this coupling matters is economic. In Refolk's index of professional profiles there are roughly 18.6 times more JavaScript engineers in India than in Poland. A deep pool makes silent substitution cheap: the architect who charmed the sales call can be swapped for whoever is free, and a generic vendor check never notices. So the unit you verify is not "the agency" and not "an engineer in the abstract" but "this named person, on this contract, proven by this signature."

What public evidence can prove, and where each source lies

Four public artifact types are usable, and each proves a narrow thing. Corporate registration proves the entity exists and names its officers; firm repos and named engineers' commit history show volume and code; and prior shipped products prove something was built. None of them, on its own, proves who will write your code or that they still work there.

The load-bearing weakness is authorship. By default, Git and GitHub do not validate the author of a commit: with write access to a repository you can push code as any valid repo user, and anyone can set the author field to any value. A commit proves authorship only if it carries a verified digital signature. That single fact is what most agency checklists miss, and it is why a strong contribution graph under a pitched name is a false positive until you confirm the signatures.

Registry data comes from aggregators that pull filings directly from official company registries across many jurisdictions and standardize them; one such aggregator covers roughly 240 million companies across 145-plus jurisdictions. It does not create or independently verify new records. It reflects what each registry published, as of that registry's own filing date, so a hit proves existence, not currency or capability.

The IP terms that must be in writing, and where "work made for hire" fails

Ownership of custom code is a legal question that payment does not settle. Under 17 U.S.C. 201, code written by an independent contractor belongs to the contractor by default; "work made for hire" generally covers employees, and commissioned software is not one of the nine statutory categories that agreement can convert into a work for hire. To own what you paid for, the contract must contain an express written copyright assignment.

Two documented failure points sink otherwise careful buyers. The first is relying on work-for-hire language alone. In Aymes v. Bonelli, a developer built a program without an employment agreement on ownership; the company assumed it owned the software because it had paid and had used work-for-hire language, but the court found the developer was an independent contractor whose work did not fit the nine categories, so the developer owned the copyright. The second is future-tense assignment. Courts have repeatedly held that "will assign" or "agrees to assign" creates only a promise, while "hereby assigns" transfers rights immediately. A promise is not a transfer.

Beyond the assignment clause itself, four more items must be on the page: a pre-existing and background-IP carve-out, an open-source disclosure and license list, a moral-rights waiver, and an assignment trigger tied to payment. The trigger matters because the base rate for reversal is high. Deloitte's 2024 Global Outsourcing Survey of more than 500 executives found 70% had pulled work back in-house, so the contract's off-ramp, meaning code and credentials portable on notice, is more likely to be exercised than not.

A funded, deployed, working product can still be legally owned by the contractor if no one wrote the assignment down.

Why the paid trial is the single highest-validity signal

A paid trial is the strongest single piece of evidence you can buy, and you should treat it as mandatory whenever the named team cannot be independently verified from signatures and references. In Schmidt and Hunter's 1998 meta-analysis, work sample tests posted an operational validity of r = .54 for predicting overall job performance, the highest of any single selection method in their hierarchy. Later work by Sackett and colleagues in 2022 revised that figure downward, so treat .54 as an upper bound rather than a fixed constant, but the relative ranking above interviews and portfolios holds.

The mechanics: give the agency a real, contained piece of work, a single feature or a tricky bug, and about two weeks. In that window you learn more than ten calls can tell you. Scope the trial to resemble the real build, because project size predicts outcome more than vendor charm. In the 2015 Standish CHAOS data, only 6% of "grand" projects succeeded against 61% of small ones, so keeping the first engagement small is itself a risk control and makes the trial a genuine sample.

There is one trap. A clean trial deliverable is a false positive if a different team than the contracted one built it. Confirm the trial's committers are the named engineers, by verified signature, before the trial counts for anything.

Refolk collapses the slowest part of this into a sentence: instead of scraping profiles by hand to corroborate a pitched roster, you can ask for exactly the people and evidence you need and get them back across GitHub, LinkedIn and the open web. When you need to confirm that a named engineer's contribution history is real and signed, describing the person in plain English beats stitching together searches.

The procedure: from entity check to a second-reviewer verdict

Run the pass in eight steps, split across a buyer or analyst, a technical reviewer, counsel, and a second reviewer for the verdict. For a small, well-defined project the whole pass fits in one to three weeks; larger or regulated projects need several weeks for interviews, reference checks, security review and contract negotiation. Sources disagree on sequencing, and both work: run the early stages on two or three agencies in parallel to avoid the fatigue that makes the third vendor "look fine," and the trial can precede or follow final legal review.

How this goes wrong: the failure modes and false positives

Most bad verdicts come from accepting a signal that looks strong but proves nothing. Each failure mode below has a characteristic false positive and a specific check, and this is the part of the standard worth the most weight. Do not skip the check because the signal feels reassuring; a red flag is something you can point to on a page, not a feeling from a call.

Two more deserve attention. A quote dramatically below market is not a saving; it often signals an expertise gap, and even genuine-savings teams should demonstrate modern frameworks and secure practices, so treat an extremely low price as a prompt for more evidence, not less. And vetting fatigue is real: sequential reviews across three months erode your standards by the third vendor, which is why running the early stages in parallel and holding thresholds fixed is a safeguard, not a shortcut.

The stakes behind these checks are visible in the outcome data. Across the Standish CHAOS series, most projects have never landed cleanly, and a meaningful share fail outright. Undisclosed subcontracting compounds this: IBM Security data cited in the outsourcing literature found 36% of businesses suffered a breach due to outsourced vendor errors, which is a direct reason to know, in writing, exactly who touches your code.

The verdict rubric: Cleared, Conditional, or Walk Away

No single published pass/fail scale for this exists, so the thresholds below are a defensible construction, not an industry constant; state that plainly to anyone who adopts it. The rule is built from unwaivable failures. Walk Away on any one of them. Conditional where the evidence is partial. Cleared only when everything passes and a trial is delivered.

Payment structure is part of the read, not a separate negotiation. A commonly cited milestone shape is 20 to 30% upfront, 40 to 50% across two or three milestones, and 20 to 30% on final acceptance. A demand for a large upfront payment against few milestones is a red flag you can point to on the page, and 100% upfront should end the conversation.

Firm: <registered name> | Entity verified: Y/N (registry, date)
Named engineers: <names> | Verified signatures: Y/N per name
References confirming roster: <count, min 2>
IP: hereby-assigns present: Y/N | carve-out: Y/N | OSS list: Y/N | moral-rights waiver: Y/N | payment trigger: Y/N
Paid trial delivered by named engineers: Y/N | grade: <notes on questions asked, test coverage, timeline, early flagging>
Verdict: Cleared / Conditional / Walk Away
Second reviewer verdict: <matches? Y/N>

Before you call the verdict: the verification checklist

Run this last. Every item is a checkable statement against evidence you can hand to a second reviewer, not a topic to think about. If you cannot tick an item, the verdict is at best Conditional and possibly Walk Away.

Keeping the standard current

Adopt this as team policy, then re-check the two parts that drift. The validity figure for work sample tests is contested: .54 comes from 1998 and has been revised downward, so if you cite a number in a policy doc, cite the range and note the source rather than a single constant. Registry data is only as fresh as each registry's filing date, so re-pull the entity record if the engagement pauses and resumes months later.

The durable core does not move. Signatures still prove authorship, present-tense assignment still transfers ownership where a promise does not, and a paid trial by the named engineers is still the highest-validity sample you can buy. When a firm's roster changes mid-engagement, re-run the named-engineer evidence step on the new names before any of their code merges. The switch you are guarding against does not only happen before signing; it happens quietly afterward, and the same check catches it either time.