DEV Community: Ruslan Hrekov

No company, no API

Ruslan Hrekov — Wed, 07 Oct 2026 05:52:10 +0000

The engagement agent on my SMM Factory pilot does two things while the owner is cutting hair: it leaves conversational comments on in-niche Instagram posts, and it replies to incoming DMs. Haiku writes them, the orchestrator rate-limits them, Playwright drives the browser session that posts them. No approval loop — this is the one path in the system that closes the human loop entirely.

That whole stack is wrong by design. The right stack is Instagram Graph API through Meta Business Suite, with instagram_manage_comments and instagram_manage_messages write-scopes gated behind App Review. The reason I'm shipping on Playwright instead is one gate: Meta Business Verification requires a registered legal entity, and I was running this as a solo pilot without one.

This post is about what that gate actually costs when you can't clear it.

What App Review wants

The public documentation makes App Review sound like a code review with a privacy policy attached. It isn't. For any Advanced Access scope — which includes anything that writes to another user's account — you have to pass Business Verification first. Business Verification wants:

A registered legal entity with a verifiable address.
A DUNS number, or a local-equivalent registration document (incorporation papers, VAT registration, trade license).
Supporting documents on file — a utility bill or bank statement with the business name, matched against government registries Meta cross-references.
A privacy policy published on an active production domain, not a Vercel preview URL.
An explainer video of the exact user flow, demonstrating the scope's use case.

For an incorporated company this is a two-hour admin task. For a solo developer running a two-month pilot it's the whole deliverable, inverted. The gate didn't exist to filter me out specifically; it exists because this is Meta's single most-abused surface, and the business-entity check is a cheap way to make scaled spam uneconomic. By-design is the right word.

Also — there is no sandbox mode for write-scopes. Standard Access gives you read-only testing against your own account. The moment you want to write to a client's inbox or feed, you need Advanced Access, and that path begins at Business Verification. You cannot ship a demo, show it to someone, and then fix the paperwork. The shipping step is the paperwork.

What I shipped instead

A Playwright session with a long-lived IG cookie, driven by two agents:

The publisher uses the cookie to post content on Mondays after a Slack approval.
The engagement agent uses the same cookie to comment on target feeds daily and reply to DMs inline.

Comment landed · heart + thank-you from author

Started a back-and-forth with the owner

Two auto-comments the engagement agent left on in-niche accounts (Prestige Barbershop event · City Barber). Both earned author replies and hearts. This is what the cookie-session fallback actually produces — Haiku-written, Playwright-posted, per-account rate-limited enough to pass as a human reader of the feed.

Haiku generates the text. The orchestrator rate-limits by account and respects an interval floor between actions on the same thread. Everything is logged to Supabase so if an action pattern starts tripping IG's spam heuristics, the ledger can tell us exactly when the pattern changed.

This works. It also has three real costs:

The cookie rotates. When IG issues a new session cookie I have to re-authenticate manually. In the content pipeline logs you'll see this as login_required on the trends endpoint — same mechanism, different scope. For the publisher I rotate on a weekly cadence; for engagement the ambient failure rate is higher because the surface is more active.

It's outside Terms of Service. IG's TOS doesn't make a distinction between a Playwright session with your own cookie and a scraper mimicking your account. If the pattern triggers rate-limit or spam heuristics, the account is paused. The right move at that point is to apologize to the client and accept it, not to look clever.

It won't scale past a handful of clients. Session cookies are per-account. If I'm running engagement for ten barbershops, I need ten cookies, ten weekly re-auth cycles, ten rate-limit windows to coordinate. The architecture is linear-cost in client count; the Graph API path would be constant-cost in the orchestrator and linear only in client API quotas.

What the metrics lie about

The results table on the pilot's case study has one line that reads cleaner than it should:

0 IG violations · 2-month pilot

That's a true number. It's also entirely a function of running under rate limits with one client. If I'd scaled the exact same architecture to five clients, the number would've gone up. If I'd shipped under the Graph API with proper scopes, the metric wouldn't exist — compliance is the baseline, not an achievement.

Any time you see a safety metric reported on a cookie-driven system, read it as a statement about pacing, not architecture.

Should you ship this way?

Depends on exactly one question: are you running a pilot or building the product?

Pilot. One client, two-month window, honest conversation with the owner about where the automation touches their account. Playwright + cookie is defensible. You're testing whether the system is worth the paperwork before you buy the paperwork.

Product. Any plural number of clients, any plan to open a seat on a demo page. Register the entity, pass Business Verification, go through App Review. The paperwork isn't the cost of the API — it's the cost of writing to someone else's account at scale, and it's load-bearing on the whole product's story.

The failure mode is doing a pilot's architecture past the pilot. The cookie that worked for one barbershop in a two-month window is the exact wrong substrate for anything after that.

What I'd do differently

Register the entity on day one, not day sixty. The entity doesn't gate the architecture decisions — I'd still have shipped the orchestrator, the Haiku stratification, the Slack approval, the knowledge-markdown system. What it gates is which API the production version runs against, and that question needs answering before the pipeline is load-bearing on a workaround.

The pilot proved the system can run at cost. The thing it didn't prove — because the paperwork wasn't done — is whether the system could run at scale legally. Those are two different questions and I conflated them for most of the pilot.

The clean API wasn't a lie. It was a filter, pointed exactly at builders like me, working exactly as designed.

Shipping the cross-poster

Ruslan Hrekov — Thu, 01 Oct 2026 04:37:52 +0000

The previous post promised cross-posts to LinkedIn and dev.to "once Sprint 14 wires the automation." Three days later, Sprint 14 shipped and you're reading proof — this post landed on both platforms through a cron job the site runs on itself.

Here's what shipping that pipeline looked like.

The itch

Cross-posting manually dies at the third post. Open LinkedIn, strip the markdown, re-check character count, paste. Open dev.to, remember the canonical URL field, paste the body, slugify the tags, confirm. Each post is fifteen minutes of friction between "I wrote something" and "the people who follow me on those platforms can read it." After two tries you stop writing instead of fixing it.

The fix had to clear a lower bar than you'd think: it had to work, land in the correct places, and not accidentally publish the same post twice. The rest is polish.

The constraint

One decision gated everything: no dedicated service, no Zapier, no VPS. The site already deploys on Vercel and the code already lives on GitHub, so the pipeline had to live inside the repo. GitHub Actions free tier cron, scripts in the same language as the site, state in a committed file. If the cron ever misbehaves, I want git log to tell me when and why.

That ruled out LinkedIn's partner-reviewed Community Management API (multi-week approval gate for a solo-developer app) and ruled in the self-serve w_member_social scope targeting the legacy /v2/ugcPosts endpoint. Different surface, same posting outcome.

The pipeline

Three hundred lines of orchestrator (scripts/publish-due.mjs) read content/blog/schedule.yml, cross-reference .distribution-ledger.jsonl, and when a scheduled post is due and not already published, hand it to the matching publisher — lib/distribution/devto.mjs or lib/distribution/linkedin.mjs. On success, three things happen in a fixed order:

Append to the ledger ({slug, channel, publishedUrl, remoteId, ts})
Mutate the post's frontmatter (status: posted, publishedUrl, postedAt)
Commit and push with [skip ci] so Vercel still rebuilds but the cron origin is filterable in git log

The ordering is non-negotiable. If step 2 crashes, step 1 already recorded the publish — the next cron tick sees the ledger entry and skips the slug instead of double-posting. Reversing to frontmatter-first means a crash leaves the post un-marked-as-published; the next tick re-publishes.

The ledger is checked into git. Had to catch that one in review — my first draft had .distribution-ledger.jsonl in .gitignore because the filename looks like local state. GitHub Actions runners are ephemeral; an ignored ledger would see empty state on every tick and re-publish every past-scheduled post. The file isn't local state; it's the durable idempotency guard.

The three traps I almost shipped

/rest/posts vs /v2/ugcPosts. The LinkedIn docs lead you to the newer /rest/posts under Community Management API. Looks modern, has nice typed schemas. Returns 403 with a self-serve token because that surface is partner-review-gated. The legacy UGC endpoint with X-Restli-Protocol-Version: 2.0.0 (and no LinkedIn-Version header) is what self-serve apps actually get. A full afternoon vanished before I noticed the two docs sets live in parallel universes.

Refresh tokens don't exist on self-serve. The access token is sixty days. The weekly refresh worker I wrote assumed a refresh token would arrive — none did. Not a bug; an empirical limit of the w_member_social scope. Fix was a graceful no-op with a cliff-countdown warning, and a calendar reminder two weeks before expiry to re-run the OAuth handshake manually.

Company Pages aren't optional, but they're one-time. My app wouldn't bind to a personal profile; LinkedIn's post-2019 verification chain wants a Page as the ownership anchor. Created a minimal Page in fifteen minutes, bound the app, then never used the Page again. All posts go to the personal profile via urn:li:person:XKuTKDehCv.

What runs now

Hourly on 15 * * * *. Twenty-one seconds end-to-end on a cold GitHub Actions runner. On ticks with nothing due, the output is one line — [publish-due] nothing due at <iso-timestamp> — and the job exits clean. On ticks with a due post, you see the publish lines, the devlog entry, and a cron commit landing in main.

The first live run shipped the previous post, Launching the journal, to both platforms. That post went live manually because I needed to validate the renderers against real APIs before trusting the cron. This post is the first one going through the full automated path — authored, scheduled, pushed, published by the machine, with a commit back on main to prove it.

What this post itself proves

You're reading a Build Log about a cross-posting pipeline. If you found it on dev.to or LinkedIn, that pipeline is what put it there — the schedule-driven path with no manual step between my git push and your scroll.

The whole thing is in the open: three hundred lines of orchestrator at scripts/publish-due.mjs, four invariants locked into STABLE_LOGIC.md, the full ship retro at DEVLOG.md. Clone the repo, read the cron, run the dry-run — the pipeline isn't a demo of a clever idea, it's the thing that made this very post appear in two more places than I had to type.

Launching the journal

Ruslan Hrekov — Thu, 01 Oct 2026 02:27:51 +0000

The site had five case studies and no place to put anything shorter. Everything I wanted to write about — a debugging trace, a pattern that keeps paying off, a skeptical read on a tool the timeline is excited about — needed the same weight as a full case study or it got dropped. That's the wrong shape.

What this is

/blog supports four formats:

Case Study — long-form, receipts attached, commit hashes referenced.
Build Log — chronological, dated, mid-work. This post is one.
Field Note — skeptical take on something popular. Short, arguable.
Pattern — a rule I keep applying, why, and when it breaks.

Each post lands with reading time, tags, and (where relevant) a Receipts aside — links to the actual commits, prompts, or artifacts behind the claims. If I can't cite it, I don't write it.

Under the hood

MDX with frontmatter validated at build time (invalid frontmatter throws).
/rss.xml is generated from the same source with CDATA descriptions.
Google Search Console meta tag ships via env var, so the feed shows up.
Analytics: GA4 with IP anonymisation, off by default for EU visitors until you click accept. proxy.ts (Next.js 16's edge middleware convention) reads Vercel's x-vercel-ip-country header and sets a geo-eu cookie so the client knows which path to render.
No third-party tracking beyond that. No newsletter form yet.

What's next

First real posts land over the next two weeks — one Field Note on prompt patterns that stopped working when I moved from Sonnet to Opus, one Build Log on Sprint 11 itself, and a Pattern write-up of STABLE_LOGIC.md (the file that keeps AI collaboration from unwinding your own fixes).

Subscribe via RSS, or wait for the LinkedIn + dev.to cross-posts — Sprint 14 wires the schedule-driven automation that lands this very post on both platforms.