Ihor Voronov

Case study 01 · In daily use

Marketing operations platform

An internal platform that runs the daily work of a three-person performance marketing team: launching campaigns, syncing spend every hour, sending conversions server-side, watching account health, and an AI analyst in Telegram that proposes changes for a person to approve.

Results at a glance

3 peopleuse it daily
100+ad accounts, with 100+ campaign launches a month
Up to USD 3,000/dayspend managed, up to USD 3,000 a day
~20 → ~5 minper campaign launch

Project facts

RoleDesigned and built with AI coding agents. I wrote the specs, reviewed and gated every release, and operate it.
PeriodSince December 2025
StackNode.js, Express, Next.js, React, PostgreSQL, Prisma, Python, MariaDB, PM2, nginx
IntegrationsMeta Marketing API, Meta Conversions API, Telegram Bot API, Hermes Agent
01

Problem

The team runs 100+ campaign launches a month across 100+ ad accounts. Launching meant repetitive manual setup in Ads Manager, spend was visible once a day, and conversion data lived in several tools. A launch took about 20 minutes and small mistakes were easy to make.

02

What I built

One control panel with a launch agent, an hourly data pipeline and a self-hosted attribution layer. People act from the panel or from Telegram; the AI analyst only reads and proposes.

Platform architecture Meta Ads feeds an hourly spend sync into the panel database. The attribution layer receives clicks and postbacks and sends conversions to the Meta Conversions API. Clicks and conversions from the attribution layer feed the panel's reports. The panel drives the launch agent and the Telegram bot. Hermes reads panel data through a read-only API and sends proposals for human approval. Meta Ads Attribution layer Conversions API Panelrules · reports · logslaunch agent Telegram bot Hermes (AI analyst) Person: “Yes”

Illustration. Simplified architecture of the platform.

03

Key parts

Campaign launch automation

Create Launch form with product, name prefix, ad account, country, budget, age range, launch mode, placements and link source
Demo data. Structured launch form.
  1. A structured form with presets replaces manual setup in Ads Manager.
  2. Preflight checks before anything is created: payment, access, pixel, tracking freshness and duplicates.
  3. Dry-run first, then an idempotent apply. A partial launch resumes from a checkpoint instead of starting over.

Result: a launch went from about 20 to about 5 minutes.

Launch analytics and decision rules

Decision queue with cut, add-budget and landing-page recommendations per product and country, each with its reason and an action button that asks for confirmation
Demo data. Decision queue with explained recommendations.
  1. Deterministic rules decide; each row in the queue shows the numbers and the reason behind it.
  2. Rules are backtested on past launches before they are trusted.
  3. An AI summary explains the queue in plain language; the rules stay the source of truth.

Spend and conversion data

Overview dashboard with contact, sales, Conversions API and inventory tiles, spend, revenue and profit for today, a seven-day profit chart and top ad accounts by spend
Demo data. Overview dashboard.
  1. Spend is synced every hour instead of once a day, with retries and reconciliation so no hour goes missing.
  2. Conversions go server-side to the Meta Conversions API and through S2S postbacks; personal data is hashed.
  3. Spend, revenue and profit per account and campaign in one view.

Attribution layer: taking an open-source tracker to production

I forked an MIT-licensed open-source tracker and rebuilt the backend core, data layer, test gate and operations tooling; the admin UI was inherited and extended. It replaced a commercial tracker (Keitaro) in production in early September 2026. My part: rule-based traffic routing, postback attribution, outgoing S2S delivery, Meta Conversions API, spend import, reports and role-based access.

Why the database changed: a load test at 25 requests per second with clicks and conversions mixed lost 434 of 15,000 clicks (2.9%) on the original SQLite storage. Every lost click matched a "database is locked" error, while the server still answered "OK", so the loss was invisible in status codes and the missing clicks made their postbacks fail. After moving to MariaDB the same test lost 0 of 15,000 clicks and 0 conversions, with no duplicates or locks.

434 of 15,000clicks lost on the original SQLite storage (2.9%)
0 of 15,000clicks lost after moving to MariaDB
  1. 33 versioned migrations, each with its own verification check.
  2. A release gate of 608 tests: no passing results for the exact code, no release.
  3. 20 tagged releases, each with a written evidence file.

Telegram control bot

Product A · CH · Broad
Today: spend $84.20 · CPM $6.10 · CTR 2.9% · CPC $0.21
Funnel: 352 visits · 151 product page clicks · 12 contacts · 5 sales
CPA $16.84 · ROI +38%
Today7 daysPause+20%
Raise the daily budget from $100 to $120?
YesNo
Done. Daily budget $120. Logged.

Demo data. Reconstruction of the bot's campaign card.

  1. Lists of active and paused campaigns, one button per campaign.
  2. A campaign card with spend, CPM, frequency, CTR, CPC, funnel, contacts, CPA and ROI for today, yesterday, 7 and 30 days.
  3. Pause, resume and budget changes (±20% or an exact amount) only after "Yes" and within the panel's limits: ±50% per change and a daily budget of at most $200.
  4. Each team member links Telegram in the panel and sees only their own ad accounts; every action is logged. No AI model in the loop.

Hermes, an AI analyst in Telegram

Visits look expensive for Product B in DE. Is it the creative or the product?
Neither yet. Meta CPC is $0.35, but only 55% of clicks reach the page. Check page speed and the redirect first.
Break-even for Product B × DE (revenue $19.00 per sale, 1 sale per 34 product page clicks): product page click ≤ $0.56, visit ≤ $0.24. For +100% ROI: ≤ $0.28 and ≤ $0.12. Current product page click: $1.48.
Keep products and countries separate in every review.
Noted. Every review now calculates per product × country only.

Demo data. Reconstructed from a real analysis with synthetic numbers.

  1. Deployed and integrated on the open-source Hermes Agent: a scheduled daily brief, answers to questions, recommendations with evidence and confidence, and drafts for new launches.
  2. The panel calculates, the agent explains: Hermes reads panel data through a read-only API key.
  3. Write actions can only go through an approval broker and the launch agent. Direct write access was removed after my own production audit.
  4. In use since August 2026: 43 sessions, about 3,100 messages, about 700 tool calls and 37 scheduled runs.

Monitoring, alerts and comments

Ad accounts page with spend today, lifetime spend, 20 of 22 accounts working, business manager groups, limits, balances and an archived account
Demo data. Ad account health.
  1. Health checks for ad accounts, pixels and pages, with a clear status for each.
  2. Alerts when the cost per lead jumps, conversion rate drops or a pixel stops sending events.
  3. Comment moderation under ad posts. Next: collecting objections, pain points and feedback for the product team.
04

Reliability and guardrails

  1. A read-only audit of the production system, then fixes shipped in phases with pre-change backups and rollback plans.
  2. About 495 automated tests, including contract tests for roles, resume logic and spend delivery.
  3. Secrets stored only encrypted; server-side roles (admin and team member) with account scope.
  4. Daily encrypted backups delivered to Telegram, verified by restoring them.
  5. Bot actions limited to ±50% per change and a daily budget of at most $200, always after "Yes".
05

Results

Spend is visible every hour instead of once a day. Roughly 25 hours a month (estimate: 100+ launches × 15 minutes saved) of manual work removed.

06

What's next

  1. Next stages for Hermes: morning and evening analyst reviews with urgent alerts, and one-tap approval of its proposals in Telegram.
  2. A decision journal that links each recommendation, approval and outcome.
  3. Comment insights: objections, pain points and feedback, summarised for the product team.

← Back to all work