Do not index
Do not index
I needed a reliable target account list for PailFlow and wanted a process I could run again without doing hours of manual research.
I used OpenCode to run and coordinate agents, plus a browser agent for directory and website research. For browser automation in OpenCode, I used different ai. I ran everything with the Ralph Wiggum technique, which means I wrote the PRD, broke it into user stories, executed in small batches, reviewed each batch, and then moved to the next one.
This post breaks down the exact workflow.
Stack and workflow model
I used OpenCode as the platform to run agents across coding and non-coding tasks. I used a browser agent to pull and verify data from Clutch, GoodFirms, G2 Services, and company websites. I used a PRD and user stories as written rules for required fields, scoring, and batch execution. I also used fixed scoring rules so the same inputs produced the same priority outcome.
The key choice was to keep data collection, validation, and scoring as separate steps so every ranked record had clear evidence.
The 4-step process I used to build the target account list
1) Pick sources
I set source targets to Clutch 20, GoodFirms 15, and G2 Services 15. This kept one source from taking over the list and gave me better coverage.
2) Enrich signals
For each agency, the browser agent captured delivery signals from the website, including implementation language, handoff model, and scope clarity. It also captured hiring signals for PM, delivery, and program roles, plus process-scaling and case-study evidence when available.
3) Score and rank
I used fixed checks in this order: disqualifiers, ICP checks, 2-of-3 signals, intent score, then priority and tier. Intent scores from 0 to 6 mapped directly to
P1, P2, and P3, so ranking stayed consistent.4) Execute in batches with Ralph Wiggum
I ran fixed batches of 5 records. After each batch, I logged progress and blockers before continuing. I then ran source QA and final QA before handoff.
What QA actually looked like in the PRD
The PRD had three QA layers.
First, batch monitoring happened every 5 records. I reported source progress (
x/y), accepted, skipped, and pending counts, plus skip reasons and blockers. This was a progress check, not the final quality audit.Second, I ran source-close QA. Clutch QA checked for missing fields, duplicates, and disqualifier violations. GoodFirms QA checked completeness, duplicates, and scoring consistency. G2 QA checked missing fields, duplicates, and rule violations.
Third, I ran global QA before handoff. I confirmed exactly 50 records, no duplicate domains across all sources, and that each included row had evidence, score, priority, and confidence.
How to apply this pattern
If you want to copy this workflow, define your fields and validation order before sourcing starts. Set source quotas so your list stays balanced. Keep scoring rules fixed and documented. Run small batches and log progress each batch. Then run source-close QA and final global QA before outreach.
A browser agent helps with speed, but reliability comes from the rules around the run.
Conclusion
The lesson is not "write a better prompt." The lesson is "build a better workflow."
Using OpenCode, a browser agent, and the Ralph Wiggum technique, I built a target account list that I can explain, trust, and rerun.
I'm building PailFlow in the open and sharing how I use AI systems to scale a one-woman business. You can follow the build log on YouTube. If you want to implement PailFlow with your team, sign up here.
Written by
.png?table=block&id=9ba33ac6-8e12-48f6-b980-4333b612ec56&cache=v2)
Lola
Lola is the founder of Lunch Pail Labs. She enjoys discussing product, app marketplaces, and running a business. Feel free to connect with her on Twitter or LinkedIn.