DEV Community: keith

What 40 recent Base launches look like in the data (free 20-row sample)

keith — Tue, 22 Sep 2026 13:09:07 +0000

A small sample is more useful than a loud claim. I reviewed 40 recent Base launches and pulled 20 rows so the measurement choices are visible. This is a descriptive snapshot, not a leaderboard or a prediction.

Scanner: https://anansidata.xyz/scanner.html

Free 20-row sample

token	venue	liq ETH	funded	clean	status
XCHAT	V2	1.59	1m	no	unknown
1KTO100M	V2	1.57	1m	no	alive
MAG7Xon	V2	2.50	0m	no	alive
LAPTOP	V2	1.44	1m	no	alive
BILLY	V3	4.00	0m	yes	alive
SPCX	V2	1.61	1m	no	alive
LJOHN	V2	2.50	0m	no	alive
GB	Aero V2	2.19	0m	no	dead
cobee	V2	15.20	1m	no	alive
1KTO100M	V2	1.48	1m	no	dead
MILO	V3	1.04	0m	yes	alive
CHUBBY	V2	1.58	1m	no	dead
BELONG	V2	9.19	0m	no	alive
LIQUIDBGT	V2	1.49	1m	no	dead
JBLon	V2	2.50	0m	no	alive
XCHAT	V2	1.58	1m	no	dead
SPY	V2	2.52	0m	no	alive
XCHAT	V2	1.47	0m	no	dead
LIQUIDBGT	V2	1.54	1m	no	dead
Grok	V2	15.22	0m	no	alive

In these 20 rows, 2 are marked clean, 12 are alive, 7 are dead, and 1 is unknown. The useful questions are how “clean” was defined, how quickly liquidity appeared, and which findings can be independently checked on-chain. Treat the sample as a starting point for inspection, not a conclusion.

Full pack — $5: https://buy.stripe.com/00w14pgOKeuUcJM72C2ZO0e

Not investment advice. AnansiData only.

10 cold emails I keep ready so freelancing outreach isn’t a blank page

keith — Tue, 22 Sep 2026 13:06:34 +0000

Cold outreach works best as a useful note, not a pitch blast. Here are 10 prompts I keep ready:

Observation: I noticed [detail]. One idea for [outcome] is [suggestion]. Want the short version?
Audit: I found one testable improvement on [page]: [observation]. I can send the first steps.
Example: A recent project solved [problem] with [tactic]. Want the summary?
Question: Are you focused on [priority A] or [priority B]? I can share a checklist.
Resource: This guide may help with [problem]. It includes [useful detail], with no pitch attached.
Launch help: Congrats on [milestone]. I help with [deliverable] and can outline a fix for [friction].
Results: I help [client type] improve [outcome] with [method]. I can share the framework.
Referral: I thought of you for [need] because [context]. If someone else owns it, could you point me to them?
Follow-up: One concrete thought: [observation]. It should take [time] to test. I can send a plan.
Graceful close: I’ll close the loop. If [problem] becomes a priority later, reply “send it” and I’ll share the outline.

Follow-up rhythm

Send the first note only with a real reason. Follow up twice at most: once with new value after 3–5 business days, then a close a week later. Stop when someone says no or asks not to be contacted.

Anti-spam checklist

Use a verifiable personal detail and one clear next step.
Be honest; avoid fake urgency, hype, attachments, and misleading subjects.
Include an easy opt-out, honor it, and suppress opt-outs.
Respect laws, platform rules, and recipient preferences.

The goal is a relevant note the recipient can quickly assess.

Cold Email Script Pack for Freelancers — $5 — https://buy.stripe.com/00w14pbuqbiIaBEbiS2ZO0d

Standalone PDF. Instant after checkout.

The onboarding step I stopped skipping: writing down the handoff

keith — Mon, 21 Sep 2026 16:18:05 +0000

A small freelance project can feel straightforward right up until the first handoff.

The brief looked clear. The client seemed aligned. The deadline was reasonable. Then a familiar set of questions appeared in different places:

Which file is the current one?
Who is approving this?
What exactly counts as “done”?
Where should the final copy live?
What happens if the scope changes halfway through?

None of these questions is difficult on its own. The expensive part is answering them repeatedly, in the middle of production, with slightly different assumptions each time.

The process lesson for me was simple: onboarding is not an administrative preface to the work. It is the first piece of the work.

Start with a one-page project brief

Before opening a task board or drafting a first version, I try to capture five things in plain language:

The outcome: what should be true when the project is finished?
The audience: who will use, read, or approve the result?
The constraints: deadline, format, channels, technical limits, and anything that is explicitly out of scope.
The decision-maker: one person who can give the final yes or no.
The evidence of completion: the file, link, launch, or other observable result that closes the project.

This does not need to become a long proposal. If the summary cannot fit on one page, that is often a signal that the project still has unresolved questions.

Turn assumptions into small confirmations

Freelancers are often rewarded for being proactive, but guessing silently is a risky version of proactivity. I now separate assumptions from decisions and ask for confirmation on the assumptions that could change the work.

For example:

I’m assuming the first draft covers the homepage and pricing page, with one revision round. I’ll deliver the final copy in the shared document by Friday. Is that the right boundary?

That message does three useful things: it gives the client something concrete to correct, creates a written record, and keeps a small ambiguity from becoming a large scope conversation later.

Keep the first handoff boring

A good first handoff is easy to scan. Mine usually has:

what I completed;
links to the current files;
open questions, if any;
the specific feedback I need;
the next date or decision point.

I avoid sending a paragraph that mixes status, questions, and new ideas. Separate sections make it easier for a busy client to respond—and easier for me to see whether the project is actually moving.

The same principle applies to filenames and folders. A predictable structure such as 01-brief, 02-working, 03-review, and 04-final is not exciting, but it reduces the number of tiny decisions everyone has to make.

Add a lightweight “pause” rule

Some requests are harmless additions. Others change the audience, promise, channel, or risk profile of the work. I use a pause rule for the second kind:

Restate the requested change.
Note what it affects (time, deliverables, approvals, or claims).
Ask whether to replace an existing item or add work.
Confirm the updated next step before proceeding.

This is especially useful when the work touches public-facing language or a client’s brand. A quick review for unsupported claims, confusing wording, privacy issues, or accidental use of someone else’s material can prevent an avoidable rework cycle.

Close the loop deliberately

At the end, I send a short closeout rather than assuming silence means completion. It includes the final link, the agreed deliverables, any remaining maintenance note, and a sentence asking whether anything is still outstanding.

That last check is valuable because it distinguishes “I sent a file” from “the client received what they needed.” It also leaves a cleaner trail for the next project.

The broader takeaway is that a checklist is not there to make a freelancer look formal. It is there to move decisions earlier, while they are still cheap to change. The best onboarding process is often the one nobody notices because it quietly prevents confusion.

If a printable version would be useful, I keep the Freelance Client Onboarding Checklist here: view the checklist. It is intentionally short and meant to be adapted to your own workflow. I also made a companion Brand Safety Checklists worksheet for projects that touch public claims or brand risk, but the process above is the part that made the biggest difference for me.