engineering
How We Check Startup Programmes
Who qualifies, what they receive and where they actually apply. How Sourcey checks startup programmes and preserves the details a short summary can lose.
An application form can be on the right website, describe an offer your startup qualifies for, and still be meant for someone else.
Agora’s VC programme is one example. Its form is for investors nominating portfolio companies. A founder needs to involve their investor; a listing that simply says “Apply here” has missed the part that determines what to do next.1
This is the work behind Sourcey’s startup listings. The large number in the headline is usually easy to find. The harder part is establishing who can use the offer, what they receive, and which route actually gets them to it.
A founder should be able to use the catalogue to decide where to spend their time. That requires keeping details a quick summary can easily erase.
An application route is more than a link
Wysera’s startup page gives an email route. It asks for the startup’s name, website, and a sentence about its growth objective. Those are actionable details: the founder knows where to go and what to prepare.
“Visit the programme page” would be a shorter listing. It would also leave the reader doing the same research again. Where the provider names a route and the information it needs, the listing should carry that through.
The page also describes the intended company. An early-stage B2B product with a relevant need is different from an agency reselling the service or an idea that has not reached the product stage. Those distinctions let someone rule an offer in or out before spending an afternoon on an application.
The practical check follows the route far enough to identify the next action. Is it an email? A signup? A partner introduction? Who performs it? What do they need to bring? A URL that loads answers none of those questions by itself.
Eligibility can change in a single word
The a55 Activate programme describes commerce startups at different stages, founders working on conversion and consumer experience, and teams replacing their checkout. Compressing that description into one narrower class of company can change who appears eligible.
Our public correction makes the problem visible. The earlier wording attached a founder condition to the commerce-startup description. The revision preserved the separate groups the programme named. It also corrected the application route from the programme overview to the signup page.
This is more than copy-editing. “A or B” admits a different set of applicants from “A and B.” A requirement, an example of a good fit, and a description of the typical customer should not become interchangeable because a shorter sentence reads neatly.
We check the relationship between conditions as well as the individual facts. Geography may be a hard limit. Company stage may define a tier. A particular technology may describe a use case rather than a prerequisite. When the source does not settle the distinction, the record needs further checking before it can confidently exclude somebody.
Longer wording is sometimes the correct result. The reader needs the provider’s rule, not the neatest sentence we can make from its vocabulary.
The applicant and the beneficiary can be different
Agora’s investor nomination route deserves a separate field because it describes a relationship. The startup receives the benefit; its investor starts the process.
A founder reading the listing needs to know whom to ask and which programme to mention. An investor needs to know that they are the person expected to complete the form. If those roles collapse into a generic application link, neither reader gets a complete instruction.
The scope also matters. This route belongs to the named VC programme. It does not establish that every Agora offer requires an investor referral. The same provider can have a direct startup application, a partner benefit, and another programme available only through nomination.
Sourcey’s record has to describe the particular offer. Otherwise, facts that are correct on one page can become misleading when applied to the whole company.
What is actually being offered?
A useful catalogue also distinguishes the kind of benefit. A credit balance, a reduced price, and someone helping your team get set up should not all be presented as cash you can spend.
Wysera, for example, describes a two-week setup programme and discounted pricing for twelve months after conversion. Its comparison with the cost of other tools helps explain the offer’s positioning. It is not a credit balance that appears in the applicant’s account.2
The distinction changes what a founder needs to ask. For a credit, ask which charges it covers and when it expires. For a discount, ask what price it reduces and what happens when the discount ends. For setup help, ask what the provider will do and what your team must supply.
These details also determine whether two listings belong in the same comparison. A big headline saving cannot substitute for a benefit that solves the problem the company actually has.
Our wording gets checked too
The corrections for Wysera, a55, and Agora include changes to our own records. Knowing the catalogue well does not make us immune to compressing a condition too far or stopping one link short of the useful route.
The correction should leave something specific behind: an email route the reader can use, an eligibility description that preserves the alternatives, or a form attached to the right applicant. Keeping the source beside the change makes it possible for the next editor to check the reasoning instead of inheriting somebody else’s confidence.
When the provider’s own pages disagree
A launch post can describe an offer that the current application no longer mentions. A benefits page may advertise a maximum while the terms attach it to a particular referral route. Two official URLs do not automatically corroborate each other.
Preserve what each page actually says, when it was checked, and which route it applies to. If the eligibility rule cannot be reconciled, say what is unresolved. Do not turn an old blog post into current eligibility simply because it contains the larger number.
Even a small grammatical change matters. “A company under five years old or with less than $1 million raised” admits a different set of applicants from the same sentence with and. That is an illustrative rule, not a provider’s offer. A useful summary has to preserve the logic as well as the numbers.
Make the research available to the reader
A structured listing should answer the questions people bring to it:
| What the founder needs to know | What the record needs to preserve |
|---|---|
| Can my company use this? | Eligibility, geography, stage, prior-benefit conditions, and any provider discretion. |
| What do we receive? | Benefit type, amount, coverage schedule, and duration. |
| Who takes the next step? | Applicant, nominator, or partner role. |
| Where do we start? | The actual application or contact route. |
| What could change the value? | Exclusions, expiry, commitments, and the price after the offer. |
| Where did this description come from? | Supporting source links and a checked date. |
A headline, FAQ, terms page, and application form may each hold a different part of the answer. Read them together. A missing condition on the landing page does not erase a condition in the applicable terms.
The programme details here were checked on 17 October 2026. The dated sources let someone revisit a condition when the provider changes it. The catalogue brings the offers together; Before You Apply for Startup Credits walks through the coverage arithmetic and the bill after the benefit ends.