Technology Sep 01, 2026 · 6 min read

I counted how many startup credit programs a machine can actually check

Startup credit programs are a filtering problem before they are anything else. There are hundreds of them, most have conditions, and the conditions are written as prose on a vendor page. If you want software to narrow that list down to the ones you might actually qualify for, the prose is where you...

DE
DEV Community
by codeboost-tr
I counted how many startup credit programs a machine can actually check

Startup credit programs are a filtering problem before they are anything else. There are hundreds of them, most have conditions, and the conditions are written as prose on a vendor page. If you want software to narrow that list down to the ones you might actually qualify for, the prose is where you get stuck. A parser can read it. It cannot evaluate it without guessing, and a guess that produces a rejected application is worse than no filter at all.

So the useful question is not how many programs exist. It is how many state their conditions in a form a machine can evaluate without guessing.

Sourcey turns out to publish exactly that number, and it publishes the data behind it under CC BY 4.0, which means the number can be checked rather than believed. That is rarer than it sounds.

The published number, and checking it

On its statistics page Sourcey reports that 21.64 percent of active offers, 95 out of 439, have an eligibility tree built only from structured predicates or constants. No human review node anywhere in the tree.

Checking that takes about fifteen lines. Download the catalog, walk every offer whose lifecycle is active, recurse into the eligibility rule, and count the ones with no node of kind manual anywhere inside:

def has_manual(node):
    if not isinstance(node, dict):
        return False
    if node.get("kind") == "manual":
        return True
    return any(has_manual(c) for c in node.get("rules") or [])

active = [o for e in data["entities"] for o in e.get("offers", [])
          if o.get("lifecycle") == "active"]
structured = [o for o in active
              if not has_manual((o.get("eligibility") or {}).get("rule") or {})]

print(len(structured), "of", len(active))   # 95 of 439

95 of 439. The percentage matches to two decimal places.

That is a good result for a dataset. The figure is reproducible from the raw file, the denominator is attached to it, and the method is stated plainly enough that disagreeing with it means disagreeing about the definition rather than about the arithmetic. Plenty of published numbers do not survive that treatment.

The interesting part is inside the 95.

Thirty of them do not ask anything

Take UpCloud's trial credits, offer off_01kyxthgq4qxtcyybqae9x11sy, 500 dollars in cloud credits, checked on 1 September 2026. The page says "1 condition". The condition, in UpCloud's own words, is "Available upon sign up for new trial accounts." Underneath it the label reads: applies to everyone.

Read those two lines together and something is off. Needing a new trial account is a requirement. An existing UpCloud customer does not meet it. But the rule is stored as a constant that evaluates to true, so any filter built on the structured data passes that offer through to everyone, including the people who are not eligible for it.

What makes this worth pointing out is that the schema handles this case fine. There is a fact called company.is_current_customer, and 50 active offers use it as a real predicate. Mux writes "Must not be an existing Mux customer". Help Scout writes "Must be a new Help Scout customer". Baseten writes "Must be net new customers who have never received any credits from Baseten". Forty-nine of the fifty compare it to false. The vocabulary exists and most records reach for it. This one did not, and the constant it fell back to is what puts it in the structured bucket.

Thirty of the 95 are shaped this way, holding no predicate at all. That count is mine, not Sourcey's, and it comes from checking which structured offers contain zero predicate nodes.

Subtract them and you are left with 65 offers, 14.81 percent of active ones, where a structured condition actually asks something about your company.

One that survives the count without earning it

Databricks for Startups, offer off_01kyyts97v21z78gt9fvpcajr2, up to 200,000 dollars in credits, checked the same day. One condition, marked checkable: stage equals startup. You have to be a startup to qualify for the startup program. A machine can evaluate that instantly and come away knowing nothing.

What a real one looks like

Neo4j's Aura credits, offer off_01kyyts97vrwvjk2hzser10zjz, up to 16,000 dollars, checked 1 September 2026. Four conditions, all four marked checkable: stage in Pre-Seed, Seed, Series A or Series B; business model not agency or consulting; a live website on record; a company LinkedIn profile tied to the applicant.

Four questions, all answerable from data a company already holds about itself. Three of them would knock out a consultancy that has started describing itself as a startup, which is the entire job of a filter. This is what the structured bucket is supposed to contain.

The manual ones are the honest ones

ActiveCampaign's incubator program, offer off_01kyh8fpdykn4q9hneqabepa3s, 90 percent off the first year, is marked "1 condition, 1 the vendor decides". The condition is a single sentence carrying four separate requirements: new customer, company under two years old, currently in an incubator or an alum from the past twelve months, and no more than a million dollars raised.

No filter evaluates that, and Sourcey does not pretend one could. The rule is tagged not-machine-evaluable and handed back. Of the 439 active offers, 198 sit in that manual bucket, split across rules that cannot be machine evaluated, rules left to vendor discretion, and rules needing verification from somewhere else.

That entry is more useful than the one asserting stage equals startup. It is accurate about how much work it is leaving to a human, which means the work can be planned for instead of discovered later.

What the number is good for

If you are automating this, the practical shape falls out of the counts. Sixty-five offers can be evaluated directly. Thirty need a person to read the statement text, because the condition is frequently sitting right there in prose even when the tree says the offer applies to everyone. The remaining 198 need a person regardless, and knowing that in advance is the difference between a filter and a queue nobody drains.

The wider point is about reading published metrics. The 21.64 percent figure is correct and it is honestly derived. It just answers a narrower question than the one it looks like it answers, and the only reason anyone can tell is that the underlying file is public and the licence permits checking. Pull the catalog, filter to active offers, recurse the eligibility trees, count the ones with no manual node, and you should land on 95 of 439 on the current release. Then count how many of those 95 hold no predicate at all. That second number is not published anywhere, and it is the one that tells you what you are really working with.

DE
Source

This article was originally published by DEV Community and written by codeboost-tr.

Read original article on DEV Community
Back to Discover

Reading List