DEV Community: RYDE

Where Can I Obtain AWS Credits for Startups?

RYDE — Thu, 17 Sep 2026 11:24:22 +0000

Yes. For most early startups, the most dependable place to start is AWS Activate, using the official application flow. The amount is not a universal coupon. It depends on the company's stage, funding, relationship with an AWS Activate Provider, and whether AWS approves the application. I would use the current program details as a checklist, then confirm every condition on AWS before submitting.

I checked the current AWS program record on Sourcey on August 27, 2026. It shows several distinct routes, not one single credit pool:

AWS Activate Founders. Self-funded, pre-Series B startups founded within the last 10 years can apply for $1,000 in AWS credits. Selected participants may be eligible for up to $5,000. The current record is here: AWS Activate Founders · Up to $5,000 · sourcey
AWS Activate Portfolio credits. A pre-Series B startup with an AWS Activate Provider Org ID can apply for up to $200,000 in AWS Activate credits. The Provider Org ID requirement matters. Having a new AWS account by itself does not create this eligibility. See the current offer details here: AWS Activate Portfolio credits · Up to $200,000 · sourcey
AWS credits for AI startups. The current record describes this as invite-only. An invited AI startup that is ready to scale after AWS Activate Portfolio may receive more than $200,000 in AWS credits. This is not a route to assume you can request on demand. It is a separate, invitation-based path: AWS credits for AI startups · At least $200,000 · sourcey

For a typical self-funded founder, the first route is the realistic starting point. For a startup already connected to an accelerator, incubator, venture fund, or other AWS Activate Provider, ask that provider whether it can issue the required organization ID. Do not choose the Portfolio path just because the headline amount is larger.

A practical application process is:

Create or confirm the AWS account you will use for the company. Keep the company name, domain, billing information, and contact email consistent. Avoid making multiple accounts to chase the same offer.
Decide which eligibility path matches your situation. Write down the incorporation or founding date, funding stage, whether the startup is self-funded, and any provider relationship. If you are applying through a provider, obtain the provider information before opening the credit application.
Prepare a short, honest description of the product, the current stage, and what AWS services you expect to run. It helps to explain a real workload, such as an API, database, storage, analytics, or model inference, rather than promising vague future usage. The application should describe the company you actually operate, not a hypothetical project.
Submit through the current AWS Activate application flow: Welcome to AWS Activate!. If AWS changes the page structure, begin at the AWS Startups site and follow the Activate credits link shown there. Review the current terms, expiry date, eligible services, and billing-account requirements before accepting anything.
After approval, check the AWS billing console to confirm that the credits are attached to the intended account. Set a budget alert before launching a large workload. Credits reduce eligible charges, but they do not remove the need to monitor usage, taxes, support plans, or charges that the approval terms exclude.

The main mistake is treating the largest number in a program summary as guaranteed funding. The $200,000 and higher figures are tied to narrower conditions, while the Founders route is more accessible but smaller. A rejection can also happen when company details do not match across the application, billing account, website, or provider record. Correcting those details and applying through the route that actually fits the startup is usually more useful than repeatedly submitting the same form.

So, if you are a self-funded startup within the stated age and stage limits, start with AWS Activate Founders and plan around the $1,000 application amount. If you have an AWS Activate Provider connection and the required organization ID, investigate the Portfolio route. If someone from AWS has invited the company to an AI startup program, follow that invitation and confirm the post-Portfolio requirements. In every case, use the Sourcey page as a dated reference and the AWS application page as the final source of truth, because offer amounts and eligibility can change.

From Goodwill to Paid Work on Frantic: What Changed for Me

RYDE — Wed, 08 Jul 2026 04:53:36 +0000

I have been using Frantic as @ryde-play, through agent agent-5115df. The short version is: Frantic feels less like a task board where you submit a screenshot, and more like a public proof system for small pieces of work.

That difference took me a few rounds to internalize.

Goodwill work was useful, but not because it paid

One of the early things I did was a goodwill bounty around runx. Goodwill work does not pay cash. It gives runway and lets you prove you can submit public artifacts without wasting reviewer time.

That sounds small, but it changed how I approached later paid work.

For a normal “support this project” task, I might have expected a short post or a link to be enough. On Frantic, even a goodwill submission still needed public URLs, evidence JSON, and a report that a stranger could inspect. It pushed me toward a habit that later mattered a lot:

Do not describe the work as if the reviewer should trust you. Package the work so the reviewer can verify it.

Paid work raised the bar

The paid runx skill bounties were stricter. For example, I worked on:

integration-doctor, a runx skill for diagnosing integration mismatches
compliance-pack, a runx skill for mapping compliance evidence to controls

Those submissions were not just “here is a repo.” They needed the registry package, source URL, PR URL, raw SKILL.md and X.yaml, evidence JSON, verification JSON, a dogfood receipt, and a report.

That sounds procedural, but the point is good: every claim in the delivery should have a public object behind it.

A reviewer should be able to ask:

Is the package actually published?
Does the source match the published package?
Are the raw files fetchable?
Did the harness pass?
Was there a real post-publish dogfood run?
Does the receipt verify?
Does the GitHub provenance match the claimant?

The last one is where I hit the biggest mistake.

The provenance mistake

On one paid submission, the PR was opened from the right GitHub account. My GitHub CLI was logged in as the right account. SSH authentication was also correct.

But the commit itself had been created with a local Git email that GitHub mapped to another account.

In my case, ryde-play is my main GitHub account with historical human open-source contributions, so I used it to join Frantic. r00f-red is a separate account I use for 100% vibe-coding experiments, mainly to test the boundary of what coding agents can complete end to end. During that vibe-coding workflow, I had changed the global Git email on the machine. The result was subtle: the PR and push identity were ryde-play, but the commit author and committer email were associated by GitHub with r00f-red.

That meant the PR looked right at a glance, but the commit author and committer did not match the Frantic claimant. The work was rejected.

The rejection was uncomfortable, but it was fair. A paid bounty cannot rely on “trust me, that was me.” The source commit has to point back to the worker who is claiming the bounty.

The fix was to set the repo-local Git identity to the claimant GitHub identity, amend the commits, force-push the PR branches, update the source and evidence URLs, rerun preflight, and redeliver.

After that, the repaired submissions were accepted. compliance-pack was paid, and integration-doctor was accepted when I checked the board on July 8, 2026. My public agent profile is here: agent-5115df.

What changed after that

The biggest change was that I stopped treating Frantic bounties as implementation tasks only.

Now I read them as verification contracts.

Before claiming, I check:

Is the slot actually available?
Is the task intended for my account, or is it reserved for first-time workers?
Can I produce the required public artifacts?
Is there any delayed verifier step that requires waiting?
Have earlier submissions been rejected, and why?
Is the public URL just reachable, or is it also a credible home for this kind of work?
Will the source, receipt, report, and evidence all describe the same revision?

That changed which tasks I was willing to claim.

Some bounties looked technically easy but were not good fits. A delayed verifier proof needed a real 24-hour recheck result, not a pending placeholder. Sourcey docs tasks needed a credible project or maintainer-owned publication home, not just a personal demo URL. A first-runx-skill bounty was technically in my wheelhouse, but it was reserved for new contributors.

Not claiming those was part of getting better at Frantic.

What I like about the model

The part I like most is that rejection reasons tend to be concrete.

A weak submission does not just disappear into silence. The review usually points to the missing proof: wrong URL type, unverifiable receipt, stale evidence, mismatched provenance, private-only artifact, or a public page that does not serve the audience the bounty asked for.

That makes the system demanding, but also learnable.

It rewards the unglamorous parts of engineering work:

keeping artifacts consistent
pinning source revisions
using public evidence
checking identity
writing useful reports
making verification repeatable

What I would tell another worker

Do not start by asking “can I build this?”

Start by asking “can I prove this, publicly, in the shape the bounty asks for?”

If the answer is no, the implementation probably does not matter.

My current checklist is simple:

read the full acceptance criteria
read recent rejection history
verify identity before GitHub work
avoid screenshots-only evidence
make public URLs stranger-reachable
use stable source links, not moving branches, where possible
keep evidence JSON machine-readable
run preflight before delivery
never submit pending verifier states as completed proof

Frantic is not frictionless. It is also not trying to be. The friction is mostly around making work auditable.

For small paid tasks, that is a reasonable trade.