There's a certain type of developer who obsesses over making things clever. Elegant abstractions. Beautiful edge case handling. The perfect architecture.
Meanwhile, someone else ships a bash script that runs every hour and quietly builds their business.
I've been thinking about this lately because I built something profoundly un-clever: a prospecting system that finds and queues potential customers automatically. It runs every few hours, searches for businesses, validates their contact info, and adds them to a call queue.
It's not smart. It's relentless.
The 80% Solution That Actually Runs
Here's what the system does:
- Searches for businesses matching certain criteria
- Extracts phone numbers and basic info
- Validates they're real businesses
- Adds them to a database for outreach
That's it. No machine learning. No fancy classification. Just web searches, some parsing, and a database insert.
In the last week, it's added over 80 qualified prospects while I was sleeping, eating, or doing literally anything else.
Why "Good Enough" Beats "Perfect"
The system has obvious limitations:
- It hits rate limits and just... stops for that run
- Sometimes it adds duplicates (the DB handles that)
- The search queries are basic
- It can't tell the difference between a thriving practice and one that's closing
None of that matters.
What matters is that every morning, there are new prospects in the queue. Not because the system is smart, but because it showed up. Again. While I was asleep.
A mediocre system that runs 24/7 outperforms a perfect system you never ship.
The Implementation Is Embarrassingly Simple
The core is just cron jobs. Scheduled tasks that fire at regular intervals:
10:00 - Find receptionist leads
13:00 - Find review management leads
15:00 - Find AI-curious businesses
17:00 - Find boring businesses that need automation
20:00 - Another receptionist pass
Each job runs a search, parses results, and inserts records. When it hits a rate limit, it logs it and stops. The next run will pick up more.
No retry logic. No exponential backoff. No distributed job queues. Just cron.
The Mindset Shift
The hardest part wasn't building the system. It was accepting that "good enough" is actually good enough.
My instinct was to:
- Build a classifier to rank prospect quality
- Add retry logic for rate limits
- Create a dashboard to monitor everything
- Build an ML model to predict conversion likelihood
Instead, I shipped the dumb version. And it works.
The prospects it finds are real businesses with real phone numbers. Some won't be interested. That's fine. The system will find more tomorrow.
When to Build Boring
This approach works when:
- Volume matters more than precision - Finding 100 decent leads beats finding 10 perfect ones
- The cost of failure is low - A bad prospect just doesn't convert, no harm done
- Consistency beats bursts - Slow and steady pipeline beats feast-or-famine
- You're the bottleneck - The system should work while you don't
It doesn't work when precision is critical, errors are expensive, or you need real-time responses.
The Unsexy Truth
Most valuable automation isn't impressive to look at. It's not the kind of thing you'd put in a portfolio or tweet about.
It's cron jobs. Database inserts. Simple scripts that run on a schedule.
But six months from now, you'll have thousands of prospects, hundreds of data points, and a business that grew while you focused on other things.
Ship the boring thing. Let it run. Move on.
The clever solution you're designing in your head isn't competing with the boring one that's already running. It's competing with nothing—because it doesn't exist yet.
Top comments (1)
This resonates deeply. I built something similar for wholesale product data — a scraper that monito