The lightest thing that satisfies the requirements is one directory on your laptop: a SQLite file, a folder of prompts, a folder of generated sites, and Claude Code as the only runtime. No server, no database service, no dashboard, no framework. Everything that looks like an application is a static HTML file generated on demand and thrown away.
The load-bearing decision: Claude Code is the application. Not a thing that helps you build the application — the thing that runs it. Every module below is a prompt file and a skill, not a service. That is what makes "no code, no hires, free" achievable rather than aspirational.
Short answer: Claude Code runs the whole pipeline unattended and fills the site and deck templates. Claude Design builds those templates — and makes the ad creative, every day. Code is the factory, Design is the workshop, and the factory calls the workshop nightly: it leaves an ad brief per prospect and waits for the creative to come back.
Everything that needs taste: the templates, the deck design, the approval screen, these documents — and the ads, every day. Session-based by nature; it cannot be woken by a cron job, so it becomes a station you visit rather than a step that runs.
The daily loop: Code leaves the night's ad briefs in briefs/. You paste them here, I build the real creative, you drop the file back. Fifteen minutes.
Everything else, because it is the only one with a filesystem, a database, a browser, git and a clock. Finds prospects, resolves decision makers, researches, scores, writes messages, fills the templates, publishes, sends, logs replies.
It generates the sites and decks by pouring content into templates you approved — those are structural, so filling them is safe. It does not make the ads. It writes the brief: ten angles from the research, five formats each, the competitor evidence. The creative is made here.
Why the ads are the exception. A landing page has a template that fixes its layout — Code fills it and the result looks made, because your WOWCube prompt pins the section order, the DOM and the persuasion mechanics and lets only brand and copy move. Fifty ads have no such skeleton: each one is a layout decision, and fifty layout decisions made unattended look like fifty generated images. That is why the ads come here, and why fifteen minutes a day is the right price for the single most visible artefact in the set.
That is the deployable surface. sites/ is what gets deployed to Cloudflare, and a local git repository for its own history; everything else never leaves the machine.
Six tables and nothing else: company, person, opportunity (pool, hiring status, score), artifact (what was generated, where it lives, approved or not), message (sent, channel, hook used), event (replies, opens, role closed). Insaight already writes into SQLite, so this extends what exists rather than replacing it. One file means backup is a copy and there is no service to pay for.
Insaight is not an input to this system — it is layers 1 through 3 already built. Its 18 MCP tools and 8 skills are the store, the LinkedIn collector and the research skills, MIT-licensed, local, already writing into SQLite. Everything else here extends its schema rather than standing beside it: Meta Ad Library read straight off its public web page — no developer account, no API key, no ID check, job boards for the hiring flag, a plain fetch of the company's own site, and email discovery. Collectors only append rows — if one breaks, everything downstream still runs on yesterday's data.
One file per step: qualify (score against profile.md, assign a pool) · find-decision-maker · research · make-site · make-ads · make-deck · write-messages. Each reads the store, does one job, writes back. Editing the system means editing a paragraph of English — which is what "I can change it by chatting" actually reduces to.
A static HTML file built from the store: one prospect per card, showing the message, the site preview, the ad sheet and the deck side by side. Approve, reject, or type a note and regenerate. It writes decisions to a local file the next run reads — no server, no login, no hosting. Regenerated fresh each session and disposable.
Claude Code deploys each approved folder to Cloudflare Pages directly through wrangler, Cloudflare's CLI — no GitHub, no CI workflow, no build step. A wildcard *.danilovicioso.com record maps each folder to its subdomain. Git still runs locally as version history; it just isn't in the deploy path. Approval and publication are the same act.
Design tools stop at producing the code, and the one-click publish they offer puts the page on their own sandboxed URL under an "unverified content" banner. That banner is deliberate — it is how a public-publishing button in an AI tool avoids becoming a phishing kit. It is also fatal here: a prospect opening their own landing page under a third-party warning strip is worse than never receiving the link.
This system's shape makes that sharper. A hundred and fifty generated pages reproducing other companies' branding, published unattended, used for cold outreach — that is a profile any hosting provider's abuse team reads twice, however genuine the intent. Somebody else's platform can pull all of it because one recipient complained.
noindex, uses only public material, and never claims to be the company's own site — that is your discipline to keep, not a platform's to enforce.Vendors charge per lookup because they sell coverage and confidence. At 150 addresses over weeks — not 150,000 — you can buy neither and still land most of them. Run these in order and stop at the first hit.
| # | Method | Hit rate |
|---|---|---|
| 1 | Just look. Team pages, press releases, contact pages, conference bios, podcast show notes, PDFs on their own domain | ~20% |
| 2 | Public commit history — anyone technical has leaked a real address into a git log | ~10%, near-certain when it hits |
| 3 | Site-wide search for the domain pattern to learn the company's format, then apply it to the name | ~30% |
| 4 | Generate the eight standard patterns and verify by MX lookup plus SMTP handshake | ~20% |
| 5 | Free vendor tiers as the last resort, ~25 lookups a month each, rotated | the remainder |
The catch, stated plainly. Google and Microsoft no longer answer SMTP verification honestly, so step 4 gives you a plausible guess, not a verified address. The real verifier is the first send — and every bounce now lands on nilovicioso@gmail.com, a real aged inbox whose reputation you are relying on. So: keep guessed-pattern addresses to two or three of the day's thirty sends, and drop an address after one bounce rather than working through the other seven patterns. Expect 65–75% coverage free against 90% paid, and treat the missing quarter as LinkedIn-only prospects.
Pools E and F invert this: legacy and owner-operated businesses publish a real address on their own contact page, so step 1 alone covers most of them. The hard pool is C, where everyone is on Google Workspace behind a catch-all.
Fully automatable and genuinely free. nilovicioso@gmail.com is the sender — an aged, real, human-looking inbox, forwarding replies to where you actually read. No domain to buy, no SPF/DKIM to configure, no three-week warm-up: at this volume an old Gmail outperforms a new domain, because the thing that gets filtered is newness.
This is the one place I would not fully automate, and the reason is not squeamishness. LinkedIn detects and restricts automation aggressively, and the account it would restrict is the same account that carries your professional identity, your Tabs history and every warm connection you have. There is no second one.
What I'd build instead — a loaded gun, not a robot. The machine prepares everything: the right person, the connection note, the follow-up, in order, in a queue. It opens each profile in your own logged-in browser with the note already written. You press send.
Twenty-five of those is about eight minutes a day. That is the entire manual cost of the system — and it sits comfortably inside the single-approve constraint, because approving the package and firing the queue are the same sitting.
| Action | Safe ceiling | Note |
|---|---|---|
| Connection requests | ~20/day, 100/week | LinkedIn enforces a weekly invite cap regardless of pacing |
| Messages to connections | ~50/day | Far more headroom than invites; the bottleneck is who accepts |
| Profile views | ~100/day | Free and useful — a view before a request measurably lifts acceptance |
| Withdraw stale invites | Weekly | Pending invites count against the cap; clear anything over 21 days |
If you decide the risk is acceptable later, the same queue can drive the browser directly with human-paced timing — the architecture doesn't change, only who presses the key. Start with your hand on it.
| Cadence | Job | Touches me |
|---|---|---|
| Nightly | Collectors refresh: new roles, filled roles, new ads, new posts | No |
| Nightly | Re-score the pool, top it back up to 100 opportunities | No |
| Nightly | Generate the site and deck; write the ad brief for each prospect | No |
| Daily, ~15 min | Build the day's ad creative in Claude Design, drop it back in | Yes |
| When I sit down | Rebuild the review page; approve or reject a queue in one pass | Yes |
| On approve | Commit and push the site; queue the email; load the LinkedIn queue | No |
| Daily, ~8 min | Fire the LinkedIn queue by hand — 20 invites, notes pre-written | Yes |
| Daily | Send 20–30 emails on human-shaped intervals; poll for replies | No |
| Continuous | Log replies and outcomes back to the store | No |
| Piece | Cost | Note |
|---|---|---|
| SQLite, git, cron | Free | Already on the machine |
| Cloudflare Pages + wildcard DNS | Free | Unlimited sites on the free tier; domain already owned |
| Meta Ad Library | Free | Read off the public page directly — no developer account needed |
| Claude Code | Subscription you have | Not incremental, but it is the real dependency |
| Insaight | Free | MIT, local, no telemetry — the largest single piece, already built |
| LinkedIn scraping (Apify) | Paid | Replaceable with a logged-in browser session; slower, more fragile |
| Email finding | Free | The five-step cascade, at ~70% coverage instead of 90% |
| Email sending + reply tracking | Free | nilovicioso@gmail.com, forwarded — no domain, no warm-up |
| LinkedIn sending | Free | Queued by the machine, fired by hand — 8 minutes a day |
Apify is now the only paid line, and it is dodgeable. A logged-in browser session can do the fetching itself — slower and more fragile than paying, and the single remaining place the "free" constraint actually costs anything. Everything else on this list is genuinely zero.
Yes. A system that runs itself still has to be handed its keys, and no amount of architecture avoids that. The honest number is about ninety minutes of clicking, plus the two hours that actually matter — and with the Gmail sender and no Meta developer account, nothing on this list has a waiting period. After that it never repeats.
The split is clean: you do anything that requires being you — a password, a payment, a consent screen, an ID upload. I do everything else, including all the configuration on the far side of each login.
| # | What you do by hand | Time | Painful? |
|---|---|---|---|
| 1 | Forward nilovicioso@gmail.com to your main inbox, generate an app password | 5 min | No |
| 2 | Cloudflare: wildcard record on danilovicioso.com, connect Pages to the repo | 30 min | No |
| 3 | Log into LinkedIn in a dedicated browser profile the machine can reuse | 15 min | No |
| 4 | Install insaight, decide Apify key vs. browser-session fallback | 20 min | No |
| 5 | Drop the templates into prompts/ — landing page, ad base, deck, message voice | 10 min | Done already |
| 6 | Write profile.md — your background, wins, numbers, what you want | 1–2 hrs | The real work |
Step 9 is the only one that matters. Everything else is plumbing you do once and forget. profile.md is read by every scoring pass, every hook, every deck and every message — a thin version of it produces a thin machine, forever. Spend the two hours. I can interview you through it if that's easier than writing it cold.
Nothing here blocks anything else. With no domain to warm and no ID check to clear, the list can be done in any order, in one sitting.
Credentials live in one local file and never leave the machine — the same local-first posture insaight already takes. Nothing here is a subscription you have to remember to cancel.
mkdir.noindex and an unguessable path, decided before the first publish.