Should I vibe code
Turn selected public social profiles into a daily AI email digest
The scraper is not what gets banned. The account whose session cookie you pasted into an env var is.
?
Their verdict, the 10 profiles price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Half of this is a cron job and half of it is a siege. The digest itself — collect posts, hand them to a model, render an email, send at seven — is a genuinely good weekend, and anything RSS-shaped will work on the first attempt. The other half is Instagram, TikTok and LinkedIn, none of which serve a profile to a logged-out script any more, all of which fingerprint headless browsers, and all of whose terms prohibit precisely what you are about to automate. The workaround everyone converges on is pasting a real account's session cookie into an environment variable, and from that moment the thing your scraper is risking is not the scraper. Then there is the quieter half: a database of what named individuals posted and when, summarised by a model. Public source, still personal data — and the second the digest goes to anybody but you, you are running a small monitoring service about people who have never heard of you. Build it for yourself, budget an hour a month forever, and keep the recipient list at one.
What actually breaks
not "if". the specific failures.
- The Instagram fetch, roughly monthly, in a different way each time — markup, then a token, then a challenge page, then a device check
- The account whose session cookie you borrowed to get past the logged-out wall, which is a real account with real followers
- LinkedIn, which treats automated collection as a matter for its legal department rather than its rate limiter
- The 07:00 job that starts returning zero posts and sends a cheerful empty digest, so a silent scrape failure looks exactly like a quiet day
- Model spend, gradually, once forty profiles a day are being summarised and nobody is watching the invoice
- A summary that confidently invents a figure or a claim and attaches it to a named person's post, in an email, in writing
- Deliverability, the first day the digest goes to more than one inbox from a brand-new domain with no SPF or DKIM
Is that you?
the verdict is a default, not a law
- You are the only recipient and the only person who minds if it misses a morning
- Sources are RSS or an official API, and you accept simply losing the platforms that offer neither
- The digest links to the original post rather than reproducing its content
- It runs on a throwaway account you would not miss, or on no account at all
- Anyone else subscribes, because that is bulk email with a list, a consent question and an unsubscribe obligation attached
- You are monitoring specific named individuals rather than accounts you would have followed anyway
- It authenticates as an account you cannot afford to lose
- You plan to sell it, which turns a personal scraper into someone else's platform-terms problem as well as your own
If you build it anyway
the checklist, then the prompt that enforces it
- RSS and official APIs first. Build every one of those before you write a single line of scraping, and be honest about which platforms you are therefore dropping.
- Never authenticate as your own account. If a session is unavoidable, use a throwaway with no social graph and treat the ban as scheduled rather than possible.
- Store the raw fetched payload before parsing it. When the markup changes, the archive is what lets you fix the parser without re-fetching and re-tripping detection.
- Alert on an empty digest. A scrape that silently returns nothing is the failure mode you will not notice, because a quiet day looks identical.
- Link, do not reproduce. A title, a short summary and a URL is a citation; a full copy of someone's post in your database is a republication.
- Mark model output as model output in the email itself, and put the link to the original next to every summary so a hallucinated claim is one click from being checked.
- Set a retention window on posts and profiles — 30 or 90 days — and write the deletion job in the same commit as the table.
- Keep it to one recipient. The moment there are subscribers you need consent records, an unsubscribe link that works, and an authenticated sending domain.
I want a daily email digest of a handful of public social profiles. Build it in
the order below and argue with me when I ask you to skip ahead.
1. Start with an inventory: for each platform I name, tell me whether a public
feed or official API exists, its rate limits, and what its terms say about
automated collection. Build only the sanctioned sources; list the refusals.
2. If I ask you to scrape a platform that gates logged-out access, say plainly
that this means authenticating as an account, and that the account is what
gets banned. If I insist, use a throwaway and never my main credentials.
3. No credentials or cookies in the repo. Environment variables only, one
place, documented, with a note on how to rotate them.
4. Persist the raw fetched payload before parsing. Parsers break; archives let
me fix them without re-fetching and re-tripping bot detection.
5. Fetch politely: one request at a time, jittered delays, exponential backoff,
a real user agent, a hard daily cap. Never parallelise the collector.
6. Alert when a source returns zero items twice in a row. A silent scrape
failure and a quiet news day send the same empty email, and I will assume
the wrong one.
7. Store only what the digest needs: post id, timestamp, permalink, a short
summary. Not full post text, not images, not follower graphs. Add a
retention window and its deletion job in the same commit as the table.
8. Every summary in the email carries the link to the original post beside it,
and the email says which parts a model wrote.
9. Send to exactly one address — mine. If I ask for other recipients, stop and
tell me that is a mailing list: consent, unsubscribe, SPF, DKIM, DMARC and
CAN-SPAM, none of which are in this project.
10. Log tokens and spend per run, and cap it.
11. Out of scope: engagement metrics, follower tracking, DMs, posting, and
anything about a person who is not a public account I chose to follow. If
maintaining four scrapers stops being fun, Dailygram is $10 a month and
the ban is theirs to absorb.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
The moment you catch yourself debugging an Instagram parser on a Tuesday night. Ten dollars a month moves four adversarial integrations onto someone whose job is keeping them working, and their ban risk is theirs rather than yours. The honest framing is not a subscription against a weekend — it is a subscription against an hour a month, forever, on code that breaks without warning and is not interesting the second time.
$10/mo is cheaper than your weekend.
The valuable part is the digest archive, not the collector, so keep sent digests as plain files — one markdown or HTML file per day in a folder — instead of only as email. Then walking away is turning off a cron job, and the platform-specific scrapers were always going to be disposable anyway. Keep the profile list in a config file rather than a database and switching to Dailygram, an RSS reader or nothing at all takes about ten minutes.
Open-source RSS generator with community-maintained routes for hundreds of sites, including the ones that stopped offering feeds.
Self-hosted agents that watch sources on a schedule and assemble digests, which is the whole shape of this product.
Actively maintained page-change watcher with notifications, and a working example of polite fetching and diffing.
Questions
The profiles are public. How is this a personal data question at all?
Because 'public' answers where you got it, not what you are doing with it. Collecting a named individual's posts on a schedule, storing them and summarising them is processing personal data, and GDPR wants a lawful basis for that even when the source was a public page. A digest you read yourself sits close to the personal-use end of the scale. A digest you email to other people about specific individuals does not, and that is the line to keep an eye on.
What is the single thing that will actually kill this project?
Not a ban and not a lawyer. Attrition. Four scrapers against four platforms that actively do not want them means something breaks most months, always at a moment you had other plans, and each fix is less interesting than the last. Nine-tenths of self-hosted monitoring tools die exactly this way, quietly, with the cron job still running against a parser that returns nothing.
Can I at least build the X or RSS half?
Yes, and it is a good project. Anything with a feed is a cron job, a template and a send — genuinely a weekend, genuinely useful, and none of the risk in this entry applies. Just be clear that you have built a feed reader with an email frontend, not Dailygram, because the platforms without feeds are the entire reason Dailygram charges money.
- GDPR Art. 6 — lawfulness of processing
- GDPR Art. 5 — principles relating to processing of personal data
- CAN-SPAM Act compliance guide (FTC)
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
RSS is a solved format and a fetch loop. Reclaim your reading.
A reader is a polite HTTP loop and a table. The only way to get this wrong is to skip the polite part.
It holds the keys to your public voice. A retry loop at 3am posts the same thing eleven times.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice