DEV Community: FirstDollarProject

Three Checks I Use Before Trusting a Startup Credit Offer

FirstDollarProject — Mon, 31 Aug 2026 18:43:43 +0000

Startup credit pages often lead with a large number. The number is memorable. The route to receiving it is usually where the real work hides.

I learned to slow down after reviewing public offers that looked current in a search result but led to old forms, missing terms, or eligibility rules that changed the meaning of the headline. Before I put an offer in a planning spreadsheet, I now run three checks: find the vendor-controlled source, record when it was read, and test the actual access path.

This is the same method I use when screening open source bounties. A listing is a lead. The source behind it is the evidence.

1. Find the page that can actually make the promise

A social post, search snippet, or community list can tell you that a program might exist. None of those surfaces can bind the vendor. I want a page on the vendor's own domain that states the benefit and gives a route to apply.

Sourcey is useful here because each catalog record links back to the page it was read from. The catalog is an index with a dated trail, while the vendor remains the authority.

Consider ActiveCampaign. On August 31, 2026, the Sourcey record for the ActiveCampaign Incubator Program said qualified early-stage startups could receive 90 percent off an annual plan for the first year. The record points to ActiveCampaign's own startup page and says it was read from that page on July 27, 2026.

That pair of links answers two different questions. Sourcey helps me find and date the claim. ActiveCampaign's page is where I confirm that the company still publishes it before I apply.

If the vendor page disappears, redirects to a generic home page, or no longer contains the program language, I stop. An old third-party description does not rescue a missing first-party offer.

2. Write down the date and the exact condition

Credit programs change quietly. A dollar value might stay the same while the qualifying stage, funding ceiling, or application route changes. A note that says only "AWS credits, up to $200,000" is too loose to be useful six weeks later.

On August 31, 2026, the Sourcey record for AWS Activate Portfolio credits described an offer of up to $200,000 for pre-Series B startups with an AWS Activate Provider Org ID. Sourcey's record shows an observation date of August 4, 2026 and links to the AWS application route.

The Provider Org ID is not a footnote. It changes who can use the offer. A startup that has the right stage but no provider relationship should not budget as if the full Portfolio amount is available.

My note for an offer therefore contains four fields:

The benefit exactly as published.
The material eligibility condition.
The application or access route.
The date I checked both the catalog record and the vendor page.

That small record makes later verification possible. It also prevents a planning deck from turning a conditional maximum into expected cash.

3. Test whether the application route matches your company

Some offers use a public form. Others require a partner, an invitation, or contact with an account manager. Those routes are materially different even when the benefit sounds similar.

Sanity is a good example. On August 31, 2026, the Sourcey record for the Sanity Startup Program described one year of the Growth plan, valued at up to $9,000, with 50 seats, private datasets, scheduled publishing, and AI assist. The same record says access is through an eligible partner or program. It was read from Sanity's startup page on July 27, 2026.

That means the first task is not completing a normal public application. It is confirming that the startup belongs to a participating venture fund, accelerator, or incubator and can obtain the required offer code. If that relationship does not exist, the advertised value is irrelevant to the current budget.

I test the route before collecting documents or sharing company information. I open the application link, confirm the company domain, look for the same program name, and check whether the form asks for a partner identifier. I do not submit the form during this check.

A five-minute verification card

For a quick review, I use this card:

Vendor-controlled source: Is the offer described on the company's own domain?
Read date: When did someone last verify the page, and when did I check it myself?
Exact benefit: Is the number a maximum, a discount, a staged award, or a selected-participant value?
Material conditions: What fact could disqualify the company before review begins?
Access route: Public form, partner membership, invitation, or direct contact?

I save the answers with the URLs. If one field is unknown, I label it unknown instead of filling the gap with an assumption.

The difference between a real program and a usable program is often one condition. ActiveCampaign's record has a public form. AWS Portfolio depends on a Provider Org ID. Sanity's route depends on partner access. All three can be genuine while only one fits a particular startup today.

That is the standard I want before an offer influences runway: a current vendor page, a dated observation, and an access path the company can actually follow.

Disclosure: This article was researched by a human and an AI agent working together on the First Dollar Project. If published, it may be entered in a paid Frantic bounty. The cited facts were checked against live Sourcey records on August 31, 2026.

I Gave an AI One Job: Earn One Dollar. Here Is What Failed First

FirstDollarProject — Mon, 24 Aug 2026 06:36:14 +0000

I started a deliberately simple experiment: give an AI agent access to research, coding, and a public project identity, then ask it to earn one dollar of new, liquid value without spending money or pretending that a prize submission is the same thing as a payment.

The balance is still $0.

That is not the headline I hoped to write, but it is the useful one. In the first round, the project found several ways that an attractive-looking earning opportunity can fail before any money reaches a wallet.

Attempt 1: a ten-satoshi finder reward with a broken payout

We found an advertised reward for submitting a working Lightning API endpoint. The endpoint was real, public, and independently verified. The submission reached the service, but its payment backend returned an LND transaction error. A fallback with a fresh BOLT11 invoice was rejected as undecodable.

Result: 0 sats received.

The lesson was immediate: an advertised reward and a valid submission are not revenue. Revenue begins when the payment settles.

Attempt 2: a real security finding that was already reported

Next, we reproduced a vulnerability in an open-source bounty target. The proof worked against the pinned bounty version, the test suite passed, and a private report was drafted.

Then we checked the public discussion carefully and found that another researcher had already reported the same receipt-validation flaw through the private channel. The rules paid only the first non-duplicate report.

We did not submit a duplicate and did not claim the bounty as pending income.

Result: $0 earned, several hours not wasted on a false claim.

Attempt 3: “open” bounties with a queue of finished solutions

One Bitcoin bounty directory showed three fresh-looking listings worth about 50,000 sats each. The GitHub issues were technically open and unassigned. That looked promising until the activity history was loaded.

The web version already had nine competing pull requests. One organizer had explicitly asked new contributors to wait while maintainers reviewed the existing solutions. The directory was not lying, exactly, but “open” did not mean “available.”

We walked away.

Attempt 4: free sats that are not yet liquid

A Lightning faucet offered a weekly free spin, daily scratchcard, and paid microjobs. No deposit was required to earn an on-platform balance. The FAQ, however, said the first withdrawal required a small deposit as an anti-abuse check.

That may be reasonable for the platform, but it fails this experiment's strict rule: the first dollar must be new and liquid without putting existing money at risk.

We did not spin, deposit, or use the casino features.

The accounting rules

This project now uses four rules:

Submitted is not earned. A contest entry has an expected value, not a wallet balance.
Platform credit is not liquid until it can be withdrawn. Minimums, deposits, and lockups count.
Duplicate work has zero expected payout when the rules say “first report only.” Check first.
Every realized dollar needs a receipt. Until then, the ledger stays at zero.

To make the pre-work check faster, we built Bounty Reality Check, a free tool that scans a public GitHub issue for activity, repository health, reward language, and signs that the bounty may already be settled. It is not a payment guarantee; it is a way to decide whether asking one more question is smarter than starting the code.

What happens next

The search continues through small open-source bounties, direct Lightning tips, and zero-deposit work that can actually be withdrawn. The public goal is still the same: earn the first honest dollar, then study what can scale.

If this field report saved you from chasing a stale bounty, you can tip the project over Lightning at FirstDollarProject@stacker.news. Tips count only after they arrive, and the next update will show the receipt—not a prediction.

Disclosure: this experiment is run by a human and an AI agent working together. The research, code, and writing are reviewed against public rules, and AI involvement is disclosed rather than hidden.

A tiny paid experiment

If you want a second pair of eyes before starting a bounty, comment below with one public GitHub issue URL. We will return a short manual evidence note in public. If it is useful, pay 2,000 sats over Lightning after delivery at strike.me/basedtc. No private repositories, account access, or payment guarantee.

The 100-Comment Blind Spot: Fixing a Bounty Checker That Looked Backward

FirstDollarProject — Mon, 24 Aug 2026 04:22:38 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

Bounty Reality Check is a free screening tool for public GitHub issues and pull requests. It checks whether the item is open, whether the repository is active, how recently it moved, whether a concrete reward is visible, and whether the discussion contains settlement language such as “bounty paid,” “winner selected,” or “submissions closed.”

The project began on August 23, 2026 as part of a zero-upfront-cost experiment to earn one new dollar by first helping other people avoid stale bounties.

Bug Fix or Performance Improvement

The initial version requested GitHub issue comments like this:

githubFetch(
  `/repos/${owner}/${repo}/issues/${number}/comments?per_page=100`,
)

That looks reasonable until an issue has more than 100 comments. GitHub paginates issue comments in chronological order, so the request returns the oldest 100 comments.

That was exactly backward for this product. A bounty usually starts with requirements and claimant messages. Evidence that it was paid, awarded, or closed is much more likely to appear near the end of the discussion. On a 347-comment issue, the checker would inspect comments 1–100 and silently ignore comments 101–347.

The result could be worse than an ordinary UI error: the app could label a settled bounty “likely live” and encourage someone to waste hours on unpaid work.

Code

I added a small, deterministic page calculation:

function latestCommentPage(commentCount: number) {
  return Math.max(1, Math.ceil(commentCount / 100));
}

The issue metadata already includes the total comment count. The checker now fetches the repository and issue first, then requests the final comment page:

const [repoResult, issueResult] = await Promise.all([
  githubFetch(`/repos/${parsed.owner}/${parsed.repo}`),
  githubFetch(`/repos/${parsed.owner}/${parsed.repo}/issues/${parsed.number}`),
]);

const commentsResult = await githubFetch(
  `/repos/${parsed.owner}/${parsed.repo}/issues/${parsed.number}/comments` +
  `?per_page=100&page=${latestCommentPage(issueResult.data.comments ?? 0)}`,
);

The evidence panel now tells the truth about the coverage:

const totalComments = issue.comments ?? comments.length;

const detail = totalComments > 100
  ? 'The newest 100 comments were scanned.'
  : 'All visible comments were included in the scan.';

My Improvements

The key decision was not to fetch every page. Doing that would improve completeness but would also turn one user action into an unbounded number of unauthenticated GitHub API requests. That would make the app slower and exhaust its public rate limit much faster.

Fetching the final page preserves the original ceiling of one comment request while moving the scan to the part of the conversation with the highest settlement value. For 0–100 comments it still scans the complete discussion. For 101 or more, it clearly discloses that it scanned the newest 100.

I verified the fix in three ways:

page selection is bounded at 1 for empty and short discussions;
counts of 101, 200, and 201 select pages 2, 2, and 3 respectively;
the production build completes successfully with the new two-stage request flow.

This is still a screening tool, not a payment guarantee. The fix makes its limited evidence more relevant and its disclosure more accurate.

Disclosure: this project and write-up were produced with an AI coding agent under my direction. I reviewed and authorized the product decisions, public identity, and submission.

Before You Work an Open-Source Bounty, Check Whether It Still Exists

FirstDollarProject — Mon, 24 Aug 2026 04:10:03 +0000

I started a deliberately small experiment: earn one new dollar from zero without spending money already owned.

Open-source bounties looked like the cleanest route. Find a funded issue, write the patch, collect the reward. The problem is that a bounty feed can be technically accurate about its own database while being badly out of date about the underlying work.

During a live audit on August 23, 2026, I found all three of these failure modes:

an Algora listing still displayed a $25 tscircuit bounty whose underlying GitHub issue was already closed;
another listing pointed to a repository GitHub marked archived and read-only;
Lightning Bounties still surfaced a 7,500-sat contributor task whose underlying issue was closed.

None of that proves the platforms are dishonest. It proves that “open” is a claim that needs fresh evidence.

So I built Bounty Reality Check, a small screening tool for public GitHub issues and pull requests:

https://bounty-reality-check.rawlz.chatgpt.site

Paste a GitHub URL and it checks inexpensive signals before you spend expensive time:

Is the issue actually open?
Is the repository archived or disabled?
When did the repository and issue last move?
Are competing pull requests or claimants visible?
Do comments contain phrases such as “paid,” “winner selected,” or “submissions closed”?
Is a concrete reward amount visible?

The result is deliberately a screening score, not a promise. Even a promising bounty deserves four questions before coding:

What is the exact reward?
What payout method will be used?
What are the acceptance criteria?
Are multiple submissions competing for one payment?

The first-dollar experiment is public at:

https://stacker.news/FirstDollarProject

If the checker saves you time, the project can receive Lightning tips at FirstDollarProject@stacker.news. More useful than a tip: send me a public bounty that fools the checker so I can improve it.

Disclosure: the tool and this article were produced with an AI coding agent under human direction. I count income only when liquid value is actually received, not when a contest, bounty, or promise is merely posted.