# Shortlisting Infrastructure Providers From Public Engineering Signals

*You can turn a one-line capability need into a ranked shortlist of three to five trial-ready providers, each backed by named public evidence.*

- Canonical URL: https://www.refolk.ai/guides/shortlist-infrastructure-providers-public-signals
- Pillar: Engineering and open source
- Format: Playbook
- Published: 2026-10-13
- Last reviewed: 2026-10-13
- Reading time: 16 min

You need to pick an API or infrastructure provider for a capability, and you want a ranked shortlist of three to five credible ones to trial instead of the random three you found on page one. This playbook is for engineering managers, technical founders, developer-relations leads, and technical sourcers. It owns the half of the job most guides skip: assembling the full candidate universe from scattered registries and directories, then cutting the abandoned and thin providers before you spend a single pilot slot.

Most vendor-evaluation articles hand you a weighted scorecard for vendors you already have in hand. That is the easy half. The hard half is discovery and disqualification, and it is the part you regret skipping when a shortlisted provider turns out to have a dead SDK or a status page that is pure theater.

## Why discovery and disqualification are a separate job from scoring

Enumeration and disqualification are separable from scoring, and the public web supports both but at different layers. Curated indexes build the candidate universe; a second, signal-based pass is mandatory because none of those indexes carry reliability or commercial data.

The mechanism matters. Curation optimizes for inclusion, not currency. A maintainer adds an entry to an awesome list and rarely removes it, so staleness accumulates silently while the list still looks authoritative. That is why a two-pass structure beats a single search: the first pass answers "who exists," and the second answers "who is still alive." Collapsing them is how a dead SDK ends up on your shortlist.

#### The four layers of provider discovery

1. **Curated meta-indexes** - sindresorhus/awesome points to ~700 topic lists; best-of-lists ranks by quality
2. **GitHub Topics** - awesome-list (9,259 repos) and alternatives (202 repos) as broad entry points
3. **Alternatives directories** - SaaS equivalents the open-source lists skew away from
4. **Community threads** - named recommendations and warnings the curated lists have not absorbed yet

*Each layer adds names the layer below misses, and none of them carry reliability data.*

Read the layers top to bottom when you want quality-ranked starting points, and bottom to top when you want breadth and the freshest community signal. The point of naming all four is that any single one leaves gaps: awesome lists over-index on open source, alternatives directories skew toward privacy and FOSS swaps rather than enterprise APIs, and community threads are opinionated but unsystematic.

## What each public enumerator indexes, and what it misses

The densest public enumerators are curated lists and GitHub Topics, but each has a blind spot you must compensate for by layering. None of them tell you whether a provider is reliable or commercially viable.

Start with the curated meta-indexes because they are already quality-filtered. sindresorhus/awesome is a directory of other lists: as of mid-2026 it indexes about 700 curated lists across programming languages, security, databases, and AI. best-of-lists goes further and ranks projects by quality, holding 23 best-of lists with about 33K stars grouped into 10 categories, updated weekly. For breadth, the GitHub Topics pages are the widest net: the awesome-list topic indexes 9,259 repositories, and the alternatives topic holds 202 public repositories that catch SaaS equivalents the open-source lists miss.

**9,259 - Repositories indexed under the GitHub awesome-list topic**

Dense enough to build a longlist, but it carries no reliability or commercial data, so it is only a starting point.

| Enumerator | What it indexes well | What it misses |
| --- | --- | --- |
| sindresorhus/awesome | ~700 curated lists by domain | Currency; entries go stale silently |
| best-of-lists | 23 quality-ranked lists, 10 categories | Enterprise APIs behind no public repo |
| GitHub Topics: alternatives | 202 repos of SaaS swaps | Skews to privacy/FOSS, not enterprise |
| Community threads | Named, opinionated recommendations | Unsystematic, no coverage guarantee |

The warning that falls out of this table: a list can itself be abandoned. Before you trust any awesome list as a live market read, check the list repo's own last commit and whether its pull requests still get reviewed. A two-year-stale list of "best document-parsing APIs" is a snapshot of a market that no longer exists.

> **Watch out:** A stale list reads like a live market
>
> An awesome list can itself be abandoned. Check the list repo's last commit and PR review activity before trusting its entries, or your longlist will be a time capsule.

## The maintenance signals that disqualify a provider

The strongest disqualification signals are commit recency, release cadence, issue responsiveness, documentation quality, and a real public status page. No single universally agreed numeric threshold set exists across all five, so practitioners combine them rather than trusting any one.

The one widely adopted, documented line is OpenSSF Scorecard's Maintained check, which only succeeds if a project is older than 90 days, because anything younger is too new to assess. This 90-day gate is mirrored by status pages, which typically publish a rolling 90-day record of uptime and incidents. The convergence is useful: a quarter is the natural evaluation horizon for both code health and operational history.

Here is what each signal proves, and what it looks like when it lies.

| Signal | What it proves | How it lies |
| --- | --- | --- |
| Commit recency | Active development on the component | Stable crypto lib goes quiet but is fine |
| Release cadence | Shipping, not just committing | Vanity commits with no releases |
| Issue/PR response | A living maintainer behind it | Bot auto-responses, no human triage |
| Docs (10-min first call) | Developer experience is real | Polished marketing docs, broken examples |
| Public status page | Operational transparency | Decorative green bar, no incident timelines |

The docs test is concrete: can your developers read the docs and make a successful API call in under 10 minutes. The reliability test is the status page, read for substance. A survey found 67% of practitioners view no status page as a red flag, and 83% say a transparent incident history positively influences their decision. That makes incident history one of the highest-leverage public signals you can read before any contact.

> **Rule:** Read the status page for substance, not color
>
> A slow, vague, or offline status page during an incident is not a status page, it is a decorative banner. Read actual incident timelines and whether postmortems were published, not just the uptime bar.

On abandonment specifically: no commits in 12 or more months is a strong signal but not definitive, and it must be combined with the other indicators above. The base rate of silent decay is high, not rare. An OSSRA audit found that 91% of audited open-source components showed no clear maintenance in the past two years. Assume decay until a signal proves otherwise.

## The full procedure, start to finish

Run these seven steps in order. The sequence is load-bearing: discovery before disqualification, disqualification before scoring, and scoring criteria locked before you contact a single vendor. Times assume a mid-size capability decision with one engineer and one engineering manager available.

#### From a one-line need to a ranked, trial-ready shortlist

1. **Define the capability and knockouts** - Write the one-line need and 3 to 5 pass/fail non-negotiables such as SOC 2 Type II, SSO/SAML, data residency, API coverage, and exit terms. Classify the provider type first (aggregator, direct lab, hosted platform, or workflow-specific). Budget 1 to 2 hours; done when you have a written capability line plus the hard knockouts.
2. **Assemble the candidate universe** - Pull names from GitHub Topics, the relevant awesome list via sindresorhus/awesome, best-of-lists rankings, alternatives directories, and community threads. Budget 2 to 4 hours; done when you have a raw longlist of 15 to 30 names with each source noted.
3. **Disqualify abandoned and thin providers** - Apply the five maintenance signals to the exact component you depend on, not the org flagship. Budget 2 to 4 hours; done when the longlist is cut to 6 to 8 survivors, each drop carrying a recorded reason.
4. **Set the weighted scorecard before deeper contact** - Build a criteria table with weights summing to 100% and a 1 to 5 rubric before contacting any vendor. Keep knockouts separate from the weighted lines. Budget 1 hour; done when the scorecard is locked and dated.
5. **Score survivors into a ranked shortlist** - Multiply each 1 to 5 score by its weight, total the results, then apply knockouts separately so a failed must-have removes a vendor regardless of total. Budget 1 to 2 hours per vendor; done when you hold a ranked 3 to 5 with all must-have failures stripped.
6. **Run a time-boxed proof-of-concept** - Integrate the top 2 to 3 finalists against your actual data over 2 to 4 weeks, measuring results rather than reading the brochure. Done when each finalist has a working integration test with recorded numbers.
7. **Decide and record the evidence trail** - Pick the winner, document the named public evidence behind every surviving and dropped provider, and keep the runner-up warm. Budget 1 day; done when you have a defensible written decision tied to specific signals.

The funnel sizing in steps two, three, and five is well documented and convergent across sources. Cap the longlist at 6 to 8 and the shortlist at 2 to 3 for the proof-of-concept; a 3 to 5 shortlist is fine going into scoring, but no more than 5 enters serious testing.

#### The provider shortlisting funnel

| Stage | Figure | Note |
| --- | --- | --- |
| Raw longlist | 15-30 | from the four enumerators |
| Survivors after maintenance cut | 6-8 | abandoned and thin dropped |
| Ranked shortlist | 3-5 | scored, knockouts applied |
| Proof-of-concept finalists | 2-3 | tested on real data |

*Each stage narrows deliberately, because more than five finalists burns pilot slots without a better decision.*

#### Published funnel benchmarks compared

| Stage | Figure | Note |
| --- | --- | --- |
| technologymatch longlist | 6-8 | shortlist 2-3 |
| dancumberlandlabs shortlist | 3-5 | PoC top 2-3 |
| rfp.wiki shortlist | 3-7 | 2-3 week RFP |

*Three independent sources converge on a 6-8 longlist and a 2-3 proof-of-concept.*

Here is where the discovery half of the job gets cheaper to execute. Reading maintenance signals across 15 to 30 candidates by hand is the slow part, and some of the richest signals are about the people behind a provider, not just its repos.

I ran this search: `Find companies offering a document-parsing API with an official Python SDK committed to in the last 90 days and a public status page.` - [see the full result list](https://www.refolk.ai/s/040pmvzprk).

*Returns providers already filtered on the two signals that most often disqualify a candidate: a live, vendor-owned SDK and operational transparency.*

I use [Refolk](/) for the parts of this funnel that are really people-and-signal questions dressed up as vendor questions: who staffs a provider's developer relations, who maintains the SDK you would depend on, and whether the engineers behind the status page actually exist.

## Setting the scorecard and reading DevRel as a maturity proxy

Set your weighted criteria and lock them before any vendor contact, because establishing criteria after reviewing proposals introduces confirmation bias. The published matrices disagree on exact weights but agree completely on the mechanical procedure.

List your criteria, assign each a percentage weight summing to 100, score every vendor 1 through 5 on each line, multiply score by weight, and total the results. One API-vendor checklist weights Security and Compliance 25%, Reliability and SLAs 20%, Pricing and TCO 20%, and Developer Experience 15%. A general software-vendor guide puts functional fit at 25% to 40% for mission-critical systems, with TCO and security commonly 10% to 20% each. Pick weights that match your risk, then do not move them.

**Weighted vendor scorecard skeleton**

```
CAPABILITY: <one-line need>
KNOCKOUTS (pass/fail, scored separately): SOC 2 Type II | SSO/SAML | data residency | API coverage | exit terms

WEIGHTED CRITERIA          WEIGHT   SCORE 1-5   WEIGHTED
Security & compliance        25
Reliability & SLA            20
Pricing / TCO                20
Developer experience         15
Functional fit               20
TOTAL                       100                 =SUM
```

*Replace the weights to match your risk profile, but make them sum to 100 and lock them before you contact any vendor.*

Now a signal the published matrices do not cover but you can read for free: developer-relations staffing as a maturity proxy. Vendors fund developer advocacy only once their docs and SDKs are real, so DevRel presence correlates with the developer-experience line your scorecard weights at roughly 15%. In Refolk's index of professional profiles, the US fields about 6.1x the developer-advocate headcount of the UK.

| Market | DevRel/Advocate professionals | Share of US baseline |
| --- | --- | --- |
| United States | 295 | 1.00x |
| United Kingdom | 48 | 0.16x |

**6.1x - US developer-advocate headcount versus the UK in Refolk's index**

DevRel presence trails real docs and SDKs, so it is a cheap proxy for the developer-experience signal nobody publishes.

Operational depth is just as lopsided, and it matters for the reliability line. The engineers who staff the function behind a status page are not evenly distributed. In Refolk's index, the US Platform and SRE pool with Kubernetes is about 4.7x Germany's, and Site Reliability Engineer dominates the US title mix more heavily.

| Market | Platform/SRE + Kubernetes profiles | SRE share of sampled titles | US multiple |
| --- | --- | --- | --- |
| United States | 1,692 | 18/25 (72%) | 1.00x |
| Germany | 361 | 15/25 (60%) | 0.21x |

The read: a provider headquartered in a thin operational market may struggle to staff the reliability function behind its status page, no matter how green the bar looks. Treat a thin local SRE pool as a flag to probe during the proof-of-concept, not an automatic drop.

> A provider in a thin SRE market may not be able to staff the reliability it advertises.

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

The disqualification pass fails in predictable ways, and every one of them has shipped a dead provider onto someone's shortlist. These are the false positives and traps to watch, with what each looks like and how to defuse it.

### The "no recent commits" false positive

A library that works correctly can legitimately go months without commits. A mature cryptographic library is the classic case. Do not drop on silence alone. Cross-check release history, whether open issues still get maintainer responses, and whether the maintainers are active elsewhere. Silence plus no releases plus dead issues is abandonment; silence alone is not.

### The healthy flagship masking a dead component

The most dangerous trap: a provider's flagship repo looks alive while the specific component you depend on is orphaned. The Signal case is the reference. Its public client activity kept shipping while the server source went quiet, with the last public commit bumping the version to 3.21 on April 22, 2020. Always inspect the exact component you will integrate, not the organization's most-starred repo.

> **Watch out:** Check the component you depend on, not the flagship
>
> Public client activity can mask an orphaned server or SDK. The Signal-Server case shows a live client hiding a dead server. Open the exact repo you will integrate and read its last commit, not the org's headline project.

### The official SDK that is secretly a community fork

A vendor may link an SDK it no longer maintains. Confirm the repo owner is actually the vendor and check the last-commit date. An abandoned community library dressed up as an official SDK is a slow-motion production incident. This is why the example query above filters on an SDK committed to in the last 90 days: it cuts the forks that stopped moving.

### The status page that is theater

A green uptime bar proves nothing if the incident history is empty or the page goes dark during outages. Read the actual incident timelines and whether postmortems were published. A page that is slow, vague, or offline exactly when you need it is decorative, not operational.

### The high weighted score hiding a dealbreaker

A strong total can mask a failed must-have. A 4.3 overall score should not override a failed non-negotiable like missing SOC 2 Type II or wrong data residency. If one factor feels that important, it belongs in your pass/fail gate, not your weighted score. The scorecard's real power is the knockout, not the average, because weighting otherwise lets a cheap, well-documented but non-compliant vendor buy back points it should never have.

> **Rule:** Gates run before the math
>
> Apply knockout criteria separately and first. A failed must-have removes a vendor regardless of a high weighted total, so no amount of developer experience can buy back missing compliance.

### Criteria written after seeing vendors, and too many finalists

Two process traps close the list. Writing your weights after you have seen the vendors introduces confirmation bias, so lock them before contact. And carrying more than five finalists into testing dilutes every pilot and burns slots without a better decision. Keep the proof-of-concept to two or three.

## Before you call it done

Verify these before you trust the shortlist. Each item is the inverse of a failure mode above, so a clean pass through this list means the common traps are closed.

#### Shortlist acceptance checklist

- [ ] The capability line and 3 to 5 pass/fail knockouts are written down before any vendor contact.
- [ ] The longlist came from at least three of the four enumerators, and each source list's own last-commit date was checked.
- [ ] Maintenance signals were applied to the exact component to be integrated, not the org flagship.
- [ ] Every SDK marked "official" was confirmed to be vendor-owned with a recent commit.
- [ ] Each status page was read for incident timelines and published postmortems, not just the uptime bar.
- [ ] The weighted scorecard was locked and dated before deeper vendor contact.
- [ ] Knockout criteria were applied separately, and no failed must-have survives on a high total.
- [ ] The shortlist entering proof-of-concept is 2 to 3 finalists, not more than 5.
- [ ] Every surviving and dropped provider has a recorded reason tied to named public evidence.

## Keeping the shortlist current

A shortlist decays the moment you finish it, because maintenance and reliability signals are live, not static. The 90-day convergence between OpenSSF's Maintained gate and the status-page uptime window gives you a natural cadence: re-check your finalists and your runner-up once a quarter.

On each quarterly pass, re-run three cheap checks. First, the last-commit date on the exact component you depend on, which catches a provider sliding toward the Signal-Server pattern. Second, the status page's 90-day incident history, which shows whether reliability is trending the wrong way. Third, whether the provider is still hiring or staffing DevRel and SRE, which is the earliest leading indicator that a provider is investing in or quietly abandoning the capability you bought. A provider that stops funding developer advocacy and lets its SDK go quiet is telling you where its roadmap went, long before the status page does.

Keep the runner-up warm for the same reason. The whole point of a defensible evidence trail is that when a signal flips, you can swap finalists without rebuilding the funnel from scratch.

> **Tip:** Re-run the funnel on a quarterly clock
>
> Because OpenSSF's Maintained gate and status-page history both run on a 90-day window, a quarterly re-check of last commit, incident history, and DevRel staffing keeps the shortlist honest with almost no new work.

## Frequently asked questions

### How many providers should end up on my shortlist?

Cap the longlist at 6 to 8 names and the shortlist at 3 to 5, then run the proof-of-concept on only the top 2 to 3. Published vendor-selection guidance converges here: more than 5 finalists creates evaluation fatigue without improving decision quality, and it burns pilot slots you cannot get back. The funnel narrows for a reason, so resist carrying a fourth finalist into testing just because dropping it feels arbitrary.

### Is this project still maintained if it has not had a commit in a year?

No commits in 12 or more months is a strong abandonment signal but not a definitive one. A stable cryptographic library can legitimately go quiet for months. Cross-check release cadence, whether open issues get maintainer responses, and whether the maintainers are active elsewhere. OpenSSF Scorecard's Maintained check only even runs once a repo is older than 90 days, so recency must be read alongside release and issue activity, not alone.

### Where do I find candidate vendors beyond page one of a search engine?

Layer four public enumerators. GitHub Topics and curated awesome lists are the densest starting point, with the awesome-list topic indexing 9,259 repositories and sindresorhus/awesome meta-indexing about 700 lists. Best-of-lists ranks projects by quality, and the alternatives topic catches SaaS equivalents the open-source lists miss. None carry reliability data, so they build only the longlist you then disqualify against engineering signals.

### Should I set my scoring weights before or after I talk to vendors?

Before. Establishing criteria after reviewing proposals introduces confirmation bias, because you unconsciously reverse-engineer weights to favor the vendor you already like. Lock the criteria table, the percentage weights summing to 100, and the 1 to 5 rubric before any vendor contact. Keep must-haves in a separate pass/fail gate so a strong weighted total cannot buy back a failed non-negotiable.

### Can a high weighted score hide a dealbreaker?

Yes, and this is the most common scoring error. A 4.3 overall total can mask a failed must-have such as missing SOC 2 Type II or no data residency. Run knockout criteria separately from the weighted average: if one factor feels important enough to override the math, it belongs in your pass/fail gate, not your weighted score. Gates run first, then the weighted total ranks only the survivors.

---

*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/shortlist-infrastructure-providers-public-signals*