Direct answer
Prepare a startup perk application packet around the provider's actual questions: company identity, eligibility, intended use, account ownership, and billing setup. Keep sensitive documents in an access-controlled location, record only their type and status in the tracker, and use the provider's current instructions as the final authority.
Why evidence preparation matters
Applications often feel simple until a provider asks for a detail that belongs to finance, legal, or an infrastructure administrator. The delay then looks like an eligibility problem even though the real issue is missing ownership or an unclear document.
The goal is not to collect every company document. The goal is to prepare the smallest packet that lets the right person answer the provider's questions accurately. That keeps review time low and reduces the chance that a secret or personal document is copied into an ordinary workspace.
Use Startup Perk List's methodology to see the difference between a public offer record and private company evidence. For a broader pre-application sequence, see the startup perk eligibility checklist.
The five evidence groups
1. Company identity
Start with facts that identify the company consistently across the form:
- registered or trading name, as requested;
- company website and primary domain;
- business email domain;
- country or region of operation;
- the name and role of the applicant; and
- a short product description that matches the website.
Do not change the company name to match a marketing nickname if the provider expects a registered name. If the public site uses a product name and the legal entity is different, prepare one sentence that explains the relationship. Consistency is more useful than adding extra detail.
2. Program eligibility
The second group supports the program's gate. Depending on the provider, it may involve an accelerator or investor relationship, funding stage, company age, business registration, or a partner referral. The form may also ask whether the company has received a similar benefit before.
Create an index rather than placing the documents in a general tracker:
| Evidence type | Private location | Owner | Status | Last checked |
|---|---|---|---|---|
| Company registration | Finance vault | Finance lead | Ready | Date |
| Partner or accelerator proof | Founder folder | Founder | Needed | Date |
| Funding information | Finance vault | Finance lead | Confirm | Date |
| Prior account history | Provider account | Platform owner | Unknown | Date |
The index can live in an internal system. The public offer note only needs the fact that evidence is required and the source that describes the gate.
The AWS Activate step-by-step guide is a good example of why route and eligibility evidence should be checked together. An application path can depend on how a startup is connected to the program, not just on the word “startup.”
3. Intended use
Write the use case before submitting. Keep it concrete:
We will use the benefit for: [service, seats, or workload]
Start date: [date or month]
Owner: [person or team]
Success check: [what we will measure]
After the offer: [budget, downgrade, or exit plan]
Avoid vague statements such as “for growth” or “for AI.” A provider may ask for more detail, and your own team cannot evaluate fit from those phrases. A short use case also helps decide whether a cloud credit, a SaaS discount, or a partner service is the appropriate offer.
4. Account and billing details
Some benefits are attached to a specific account. Confirm the account ID, workspace, organization, or subscription before the application. Confirm who can accept terms and who can see usage or invoices.
Google's startup onboarding page says that approved credits are linked to the billing account submitted in the onboarding flow. That makes account selection evidence, not a minor form field. Microsoft's Azure activation guidance similarly describes billing setup as part of activation.
Make a screenshot or note of the account identifier only in the private evidence location. Do not place an API key, password, payment-card number, or full invoice in the article system or public offer tracker.
5. Timing and source
Record when the provider instructions were checked and what still needs confirmation. Include:
- application date;
- expected response or activation step;
- expiry or review date;
- the person responsible for the next action; and
- the URL used as the source.
This turns a document packet into a reviewable decision. It also prevents a stale screenshot from being treated as current terms. When catalog snapshots go stale explains why dates belong next to claims.
Public record versus private packet
A clean separation looks like this:
| Public offer record | Private application packet |
|---|---|
| Offer name and provider | Registration or funding documents |
| Eligibility summary with source | Account identifiers and billing details |
| Review date | Screenshots, correspondence, and form drafts |
| Known limits and open questions | Personal or legal documents |
| Decision status | Secrets and access-controlled evidence |
The public record should help another founder decide whether to investigate. It should not let a stranger reconstruct the company's identity or access an account.
A practical preparation sequence
Step 1: Copy the current questions
Open the provider page immediately before preparation. Copy the question headings into a private checklist. Do not rely on a remembered form from a previous application.
Step 2: Assign each question an owner
Identity questions may belong to the founder or operations lead. Billing questions may belong to finance or an infrastructure owner. Eligibility questions may need a partner or investor confirmation. One owner per question prevents a group chat from becoming the system of record.
Step 3: Mark the minimum answer
For every question, note the smallest accurate answer and the supporting evidence type. If the provider asks for a URL, do not attach a full company deck. If it asks for a billing account, do not send unrelated invoices.
Step 4: Review for contradictions
Check that the legal name, domain, email, product description, and account owner describe the same company. Resolve a mismatch before submission or explain it in the form if the provider allows that.
Step 5: Set a follow-up date
An application is not complete when the form is sent. Set a date to check the provider inbox, account activation, credit balance, or discount status. If there is no response, record the next safe action rather than submitting duplicate applications from several accounts.
Questions founders ask
Should application evidence be stored in Startup Perk List?
No. Use Startup Perk List for public offer information, source status, and a safe summary. Store company-specific evidence in the team's private, access-controlled system.
What if I do not have every document yet?
Mark the missing item and its owner. Apply only when the provider's rules permit the missing item to be supplied later and the remaining risk is understood. A missing document is not evidence that the company is ineligible.
How do I prove a provider answer later?
Keep the provider URL, access date, relevant correspondence, and the final account status in the private packet. In the public record, state the result and review date without reproducing private correspondence.
Final review
Before submitting, read the packet as if you were a reviewer who has never met the company. Can you identify the company, understand why it qualifies, see who owns the account, and tell what the benefit will be used for? If yes, remove anything that does not help answer those questions.
Startup Perk List does not verify or approve private company evidence, and a listed offer does not guarantee acceptance. Read the provider's current terms before sharing information. For the public tracking model, see track startup perks and about Startup Perk List.
A packet that is ready for review
Consider an application that asks for a company website, a business relationship, an account identifier, and a short use case. A clean private packet could contain four entries:
| Question | Answer record | Private evidence |
|---|---|---|
| Who is the company? | Legal name and public brand relationship | Registration record |
| Why does it qualify? | Program route and stage claim | Partner confirmation or provider record |
| Where will the benefit go? | Account or workspace chosen by the owner | Account screen or identifier |
| What will it support? | Named workload and start window | Internal plan or ticket |
The packet does not need to include every document the company owns. It needs to make each answer traceable. If a reviewer asks for more, add the new request and its owner instead of attaching an entire folder.
Use a redaction check
Before uploading a document, look for unrelated names, customer data, personal addresses, payment information, passwords, access tokens, and internal forecasts. Ask whether the provider needs the full document, a field, or a confirmation. If redaction changes the meaning, keep the original in the private store and send only through the provider's approved secure channel.
Do not use a public image host for screenshots of a billing account or application status. A private link in the internal record is enough. The public offer page can say that private company evidence may be required without displaying it.
Completion criteria
Call the packet ready when each provider question has an owner, an accurate answer, an evidence type, and a safe submission route. Call it incomplete when the team is relying on a remembered requirement, an unmonitored mailbox, or a document that no one is authorized to share. This small definition reduces both application delay and unnecessary disclosure.
Audience and limitations
This article applies to founders and operators reviewing startup offers. It does not promise eligibility, provider approval, credit value, savings, availability, billing behavior, or any specific business outcome; current provider terms remain the authority.