DEV Community: Romashik

B2B Lead Research Without Getting Your Domain Blacklisted

Romashik — Sat, 03 Oct 2026 16:05:57 +0000

A good lead list is not "1,000 emails". It is a small set of people who match your ideal
customer, whose address is real, and whose first line you did not copy-paste. Bad lists do
not just waste money — they burn your sending domain. Here is the process I use.

Define the ICP before you touch a tool

Write three sentences: who exactly (role + company size + industry), what pain, what trigger
means they are in-market now (funding, hiring, product launch, tech change). If you cannot
name the trigger, you are about to buy a random list.

Sourcing that does not poison the data

Prefer primary sources. Company websites, careers pages, GitHub orgs, conference speaker lists. These are more accurate than scraped aggregators and less likely to contain traps.
Check the domain before the mailbox. Does the site resolve, load, and match the company name? Typo-domains and parked domains are how bounce rates explode.
One source per fact. Record where each field came from. If you cannot cite it, delete it.

Verify before you write

Syntax basics (name@domain.tld) are cheap — reject the obvious.
Domain/MX check. No MX record means no mailbox, no exceptions.
Role addresses are not leads. info@, sales@, noreply@ go in a separate bucket, never your main sequence.
Catch-all domains are not "verified". Mark them as risky. A "verified" badge you cannot defend is worse than an honest "unverified".

Do not trust a single checker. Run two and keep only the intersection.

Deliverability hygiene

This is where most freelancers cost their clients real money:

Warm the domain. A brand-new domain sending 500 cold emails on day one is a one-way trip to spam.
Use a custom subdomain for outreach so your main domain is insulated.
Keep bounce rate under 2%. Above it, pause and clean.
Include a real postal address and one-click unsubscribe — required in most jurisdictions.
Never buy a list and blast it. That is the definition of spam.

The opener that works

Personalization is not "Hi {FirstName}". It is one specific, verifiable line that proves you
looked:

Saw you're hiring two SREs and just moved to Kubernetes — most teams hit the same
observability gap at that stage.

That sentence comes from the trigger you defined earlier. If you cannot write one for a lead,
the lead is not qualified.

Compliance is not optional

EU/UK: GDPR/UK-GDPR — you need a lawful basis (usually legitimate interest for B2B) and a clear opt-out. Document it.
US: CAN-SPAM — real address, honest subject, working unsubscribe.
Canada: CASL — stricter; consent-based for many cases. Check before sending.

This is not legal advice; it is why a clean, consent-aware list beats a giant one.

A workable workflow

Write the ICP + trigger.
Pull 200–300 candidates from primary sources.
Check domain + MX; drop failures.
Verify emails with two checkers; keep the intersection.
Deduplicate by person and by company.
Write one personalized opener per lead — or drop the lead.
Send in small batches; watch bounce and reply; pause if bounce > 2%.
Log source and result for every field so the next list is better.

A verified list of 50 with real openers will outperform 2,000 scraped addresses every single
time — and it will not cost you your domain.

I build verified B2B lead lists with per-lead openers and deliverability checks. Details in
my portfolio.

Concurrent AI Agents: What Actually Works (Notes From Building One)

Romashik — Sat, 03 Oct 2026 16:05:20 +0000

I have spent the last few months building multi-agent systems that run unattended — watching
inboxes, scraping pages, drafting content, moving money only when a human approves. Here is
the honest list of what made them useful and what was theater.

Concurrency is not the hard part

People love the demo where five agents "think" in parallel. In practice, five agents reading
the same state and racing to write it is just a distributed-systems problem wearing a
costume. The useful concurrency is boring: independent tasks with disjoint resources.

The pattern that works:

One writer per resource. A single process owns the database/ledger. Others send it requests. This eliminates 90% of the bugs.
Idempotent steps. Every step can run twice without harm. Store the step id; skip if seen.
A queue with a dead-letter lane. Failed tasks go somewhere you will actually inspect, not into a silent retry loop.

If you cannot describe a task as "read-only" or "appends one idempotent record", it does not
belong in parallel.

Roles beat prompts

The biggest quality jump came not from a better model but from splitting one big prompt into
narrow roles:

Researcher — gathers sources, produces a facts file. Never writes prose.
Writer — drafts from the facts file. Not allowed to invent facts.
Adversary — tries to falsify the draft; flags unsupported claims.
Editor — merges, enforces format.

The adversary role is the one people skip and the one that saves you. A model reviewing its
own work is a rubber stamp. A model told "find the weakest claim and attack it" is
genuinely useful.

Give agents a memory that is not the context window

Context windows are for the current task. Long-term memory belongs in files:

facts.md — verified claims with sources.
decisions.md — append-only log of choices and why.
lessons.md — mistakes and the rule that prevents them.

Before a new task, the agent reads lessons.md. After a failure, it appends one line. This
single habit did more than any model upgrade.

Guardrails that are not optional

Confirm before external side effects. Sending an email, posting, paying — all gated on an explicit human "yes". The agent prepares, the human approves.
Spend ceilings. A hard counter that refuses the next paid call once the budget is hit.
Secret redaction at every boundary. Logs, error messages, and model inputs. Assume the model will echo whatever you paste.
Read-only by default. Any mutation is a named command, never an ambient capability.

What was theater

Agents debating each other in a loop. Fun to watch, expensive, and rarely better than one well-scoped pass plus an adversarial review.
Custom orchestration frameworks before you need them. A queue table and a few functions beat a graph engine until you have dozens of flows.
Letting agents browse freely. An agent with an open browser and no allowlist will wander into paywalls and captchas. Scope the domains.

The result

The systems that survive contact with reality are small, heavily constrained, and boring.
They do one narrow thing, log everything, ask before touching the outside world, and get a
little smarter from lessons.md. The clever parallel-thinking demos are the ones that break
first.

I build and write about practical agent systems. If you want an autonomous pipeline that
does not need babysitting, get in touch.

A Practical GEO Checklist: How to Get Your B2B Blog Cited by AI Search

Romashik — Sat, 03 Oct 2026 16:04:22 +0000

Everyone is chasing AI search traffic now, and most of the advice is either obvious
("write good content") or fake ("trick the models"). Here is what actually moved the needle
for the technical blogs I work on — a checklist you can run today.

First, understand what the AI is doing

When an answer engine cites you, it usually summarizes a paragraph or two and links the
source. That means your job is not rankings and not clicks. Your job is to be the most
quotable, self-contained, verifiable source on a narrow question.

Three properties decide whether you get cited:

Extractability — a model can lift a clean, standalone answer.
Verifiability — the claim is backed by something it can point at.
Consistency — multiple pages on the web say similar things about you/your topic.

The checklist

Structure

[ ] One <h1> that states the question almost verbatim.
[ ] A direct answer in the first 60 words. No "in this article we will explore".
[ ] <h2> per sub-question, phrased as the user would ask it.
[ ] Short paragraphs (2–4 lines). Tables for comparisons.
[ ] A summary/FAQ at the end that restates answers without new claims.

Verifiability

[ ] Cite primary sources, not other blog posts.
[ ] Date everything: publish date, "last updated", and dates on serialized data.
[ ] Show methodology in one line under every number.
[ ] Link to your own related pages with descriptive anchors (internal linking still matters — it helps the crawler understand your entity).

Entities and schema

[ ] Name your product/company consistently. Pick one spelling and never deviate.
[ ] Add Article/FAQPage schema with real values, not placeholders.
[ ] Include author info with credentials (Person schema). Anonymous posts get cited less.
[ ] Keep a stable "about" and "contact" page; AI systems use them for trust signals.

Formatting for extraction

[ ] Prefer bulleted steps and numbered sequences over long prose.
[ ] Give each section a one-sentence takeaway in bold.
[ ] Avoid hedging language ("might", "could possibly") when you actually know the answer.

What to stop doing

Keyword stuffing. It does nothing for citation and hurts the humans who do read.
Thin roundups. "10 tools you should know" with two sentences each rarely gets cited; a single deep teardown of one tool does.
Chasing every model. Optimize for extractability and verifiability; that transfers across ChatGPT, Perplexity, Gemini, and whatever launches next.

Measuring it

You cannot get a clean "AI traffic" number yet, so measure proxies:

Branded search volume — if AI answers mention you, people search you.
Direct/referral traffic to the specific pages you optimized.
Server logs for known AI crawler user-agents.
Manual spot-checks — ask the models your target questions monthly and record whether you appear. A spreadsheet is enough.

A 30-minute workflow

Pick one question your buyer actually types (use search suggestions, support tickets).
Write the direct answer first, in one paragraph.
Add 3–5 sub-questions as headings; answer each in under 120 words.
Add one table and one primary-source citation.
Add FAQ schema, publish date, and author byline.
Repeat for the next question and interlink the two.

That cadence beats a 5,000-word pillar post you never update.

I write researched technical articles optimized for AI search, with sources, schema, and a
content plan. Samples and details in my portfolio.

How I Built a Zero-Cost Opportunity Radar with Python and Playwright

Romashik — Sat, 03 Oct 2026 16:04:21 +0000

Most "opportunity radars" are dashboards that show you the same noisy feed everyone else
sees. I wanted the opposite: a small, boring pipeline that watches a handful of sources I
actually care about and only pings me when something matches. No SaaS bill, no paid APIs.

Here is the architecture, the parts that broke, and the rules I now follow.

The shape of it

Three stages, each replaceable:

Collect — a set of independent watchers (RSS, a couple of public pages, an IMAP mailbox, a Telegram channel). Each watcher writes normalized items to one queue.
Filter — rules that match on sender address (not display name) and on keywords.
Notify — one message, deduplicated by a stable id, rate-limited.

The whole thing is a few hundred lines of Python plus Playwright for the JS-heavy pages.

Stage 1: collect, but keep watchers dumb

Each watcher does one thing and exits. If a watcher crashes, it must not take the pipeline
down. I run them from cron/systemd timers, not from a long-lived process that slowly leaks
memory. A cron job that fails is obvious; a daemon that wedges at 3am is not.

For email I use IMAP with a Gmail app password and readonly=True on select. Reading
should never be able to mutate the mailbox. For every message I compute a stable dedupe key
(Message-ID if present, otherwise a hash of from + subject + date) and skip anything seen.

def dedupe_key(msg):
    mid = msg.get("Message-ID")
    if mid:
        return mid.strip()
    raw = f'{msg.get("From","")}|{msg.get("Subject","")}|{msg.get("Date","")}'
    return hashlib.sha256(raw.encode()).hexdigest()

Stage 2: filter on the address, not the name

This is the mistake I see in almost every filter I review. A rule like
if "Acme" in from_header matches "Acme Inc" <phish@evil.example>. Match the address:

from email.utils import parseaddr
addr = parseaddr(msg.get("From", ""))[1].lower()

Then match domains/substrings against that. It is a one-line change that closes an entire
class of false positives and phishing lookalikes.

Two more rules that pay for themselves:

Skip marketing. If the subject contains newsletter, unsubscribe, promo, sale, it is not an opportunity. Drop it before it reaches the notifier.
Cap the noise. Never send more than N notifications per run. If the cap is hit, say so in the message. Silent truncation is worse than no notification.

Stage 3: notify once, and log

Every outbound notification gets an append-only on-disk log with a hash of the body, not
the body itself. If a credential ever ends up in an error path, the log must not become the
leak. Redact secrets in error strings before printing:

def redact(text, secrets):
    for s in secrets:
        if s:
            text = text.replace(s, "<redacted>")
    return text

What broke

Browser pages that render in JS. requests returns an empty shell. Playwright with a persistent context fixed it, but you must target the active tab, not a new one, or you fight your own automation.
Probe noise in logs. A health check hammering an internal endpoint generated ~97% of the rows in my call log and drowned the signal. I added a prune command that only runs when explicitly invoked. Read-write by accident is how you lose data.
Full test suites hanging. A suite that pulls in network tests will hang in CI. Run the targeted tests for the modules you touched; keep the slow integration ones behind a flag.

The rules I keep

Collectors are interchangeable and disposable.
Filter on addresses; treat display names as hostile.
Deduplicate by a stable id, always.
Redact secrets at the boundary; never log raw bodies.
One notification, with its own audit line.
Read-only by default; mutation requires an explicit command.

Total cost: one machine you already have, plus free-tier model calls. The value is not the
code — it is the discipline of saying no to 99% of the input so the 1% is visible.

I build small automation pipelines and write about them. If your team needs a watcher that
actually respects your attention, I can help — portfolio below.

What 2,857 Projects Taught Me About the Road to Colosseum

Romashik — Fri, 18 Sep 2026 12:29:32 +0000

An honest, data-backed reflection for anyone who lost sleep over a hackathon — and wants the next one to count.

I spent the last cycle doing something unusual: instead of building inside the Colosseum frenzy, I built a machine that watches it. An autonomous assistant that scans bounties, reads ecosystems, scores opportunities, and lets me focus on what a human should actually do — judge, decide, ship. This reflection is what that machine surfaced about the Road to Colosseum. No hype, just numbers and the lessons they force.

Lesson 1. The bar is not "build something." The bar is 0.7%.

Colosseum's Frontier Hackathon (April–May 2026) was the largest crypto startup competition to date: 2,857 submitted projects, more than 10,000 builders, 150+ countries. Out of that field, 26 winners were named — and only 21 startups made it into Accelerator Cohort 5. That's an admission rate of 0.7%.

A 0.7% funnel changes how you work. "Build something cool" is not a strategy; that's how you become one of the silent 2,831. The only honest framing: you are entering a startup competition with pre-seed money at the end, and the odds are startup odds. Which means team formation, problem selection, and ruthless scope discipline matter more than how many features you can crudely ship in a weekend.

Lesson 2. Winners look like a thesis, not a demo.

Look at what judges actually picked. Grand Champion: CrowdBrain — a vertically integrated robotics DePIN network for training and routing operators to physical robots. Not a dashboard, not a "bridge but better." A thesis: hardware × crypto × labor market, with an opinion about who gets paid. The rest of the cohort spans DePIN, DeFi, gaming, consumer finance, and RWA infrastructure.

A pattern: winning entries tend to sit inside a category (DePIN, payments, infra) rather than a "dApp of the week." Sponsors in Frontier — Phantom, Altitude, Arcium, World, Metaplex, Raydium, Reflect, Coinbase — are infrastructure and distribution, and they reward projects that slot into real rails. When you pick a problem for Road to Colosseum, ask: which existing rail does this make money for? If none — the judges see it too.

Lesson 3. Judges optimize for adoption-fitness, not polish.

From Colosseum's own guidance (their "How to win a hackathon" post), the program is designed to take teams from devnet to mainnet in 8 weeks, ending in a private demo day with VCs. That means every submission is evaluated as a potential company: distribution, go-to-market, defensibility. Polished UI without a user path is a liability, not an asset.

Do the math you can defend in front of an investor in 60 seconds: who is the first paying user, and why you specifically? If you can't say it out loud, the judges can't either.

Lesson 4. The fastest builder in 2026 is a two-person team: you and your agent.

A few honest notes from someone who shipped with heavy AI assistance:

The assistant compressed discovery: instead of reading 200 bounties and 50 ecosystem posts, I get a ranked digest — what's open, what pays, who sponsors, what's due. That's one or two saved days per cycle, every cycle.
It made failure cheap: drafts, scoping docs, competitor scans in minutes. Cheap iterations are a genuine competitive advantage in a 5-week hackathon.
It did NOT make decisions. Every important call — which problem, which team, when to stop polishing — still happened in a human head. Anyone telling you the agent decides is selling you something.

Lesson 5. The hidden tracks are the smart tracks.

Frontier quietly included two special prizes: the best university team and the most complete public goods project — each $10,000. In a 2,857-project field, the number of teams competing specifically for those prizes is an order of magnitude smaller. Same prize pool, better odds. For Road to Colosseum, same logic applies: find the category with fewer whales and more substance. Public goods, education, regional ecosystems (Vietnam building culture is real — Superteam Vietnam knows) are where well-executed projects win prizes disproportionate to their effort.

Lesson 6. The 0.7% crowd out-builds, not out-ideas.

The difference between a strong submission and a winner is rarely the idea — it's the evidence of progress: a working product, a live testnet, a clear architecture, commits you can point to. Colosseum's CTO and judging ecosystem leaders have seen every pattern; they can smell a slideware submission in the first pass. Show the thing. The pitch deck is dessert.

The Road to Colosseum checklist (what my assistant now runs daily):

Scan open bounties/grants weekly (Superteam earn, Eternal sprint, hackathon channels). Filter by fit, not by prize size.
Pick ONE category thesis; write it in one sentence; kill anything that doesn't serve it.
Test distribution before code: who is the audience, where do they gather, what will make them click.
Ship a vertical slice in week 1 — not a dashboard, a user journey on one screen.
Public progress: weekly X/dev.to post, commit log public. Judges read; communities reward.
Target a hidden track (university, public goods, regional) unless your thesis is clearly top-0.7%.
Last 48 hours: cut scope, not sleep. A working 80% beats a broken 120%.

On the level: Frontier took 2,857 projects and funded 26. The next one — the Road to Colosseum cycle — will likely be bigger, because 2026's builder base learned they can ship in weeks, not months. That's the honest deal: more competition, more eyes, and for a well-scoped, honestly-built project, more distribution than any solo article can buy.

I built a machine to watch this race so I can spend my time running it. The next hackathon is not about who codes the most — it's about who decides the most. Decide early, decide with data, and show the thing.

— A builder on the road to Colosseum