It was 60-something DM conversations sitting unread. Half of them from people who had clearly expected a response over the weekend. A few had followed up. One had already moved on and left a slightly irritated reply.

We had set up comment automation on a reel Friday evening and not thought about it since.

The idea, quickly

Someone comments a word on your post. They get a DM from you instantly. You are not there. The tool handles it — through Instagram’s official API, so your account is not at risk.

You pick the keyword, write the DM, set it live. Every person who comments that word gets the message the second they hit post.

That is the whole thing. ManyChat is what we used.

The first run

The post was a reel about building a content calendar without a scheduling tool. Nothing special about it. It was doing okay before we touched it.

Keyword was PLAN. Caption said: comment PLAN and I will send you the template we actually use.

No boost. Organic only.

Around 340 people commented in the first six hours. Every one of them got the DM.

I had sent broadcast DMs before. To lists, to followers. Open rates sit around 30 to 40 percent on a good day. When the dashboard showed 84 percent on these, I stared at it for a second and then checked again.

It was right.

The reason is simple. Someone who just commented on your post is not a cold contact. They raised their hand a minute ago. The DM lands while they are still thinking about you. That is a completely different thing from a message that arrives out of nowhere.

The comment section finished with about 3x more than we normally get on that kind of post. People saw others commenting and joined in. The algorithm noticed the spike and pushed the reel further. That part was not the plan. It just happened.

Then the Google reel happened

A few months later, we tested it on a giveaway reel themed around Google’s Free Kit, offering followers a chance to win Google-branded merchandise. The keyword was FREE.

FREE is the kind of keyword I would normally say to avoid. One word. Too common. People type it in regular conversation without meaning anything by it.

But here it was different. Every single person watching that reel was watching because they wanted the free kit. FREE was not a word they might casually type. It was the reason they showed up.

I was checking the comment count sometime that afternoon and just stopped.

FREE. Free. free. One person typed Frre. Got the DM anyway — ManyChat is forgiving with typos that are close enough.

The comments would not stop.

Then I checked the stats the next morning.

135,000 comments. 32,800 likes. 39,100 shares. 8,198 saves.

We picked up 20,000 followers that week.

ManyChat sent every one of those DMs — the giveaway details, the registration link — without a single one going out late. Nobody on the team touched the comment section. Nobody manually replied to anything. The only job left was the inbox, and that is where we made our biggest mistake.

I want to be clear about something. The reel going that big was not the automation. That was the content. The automation’s only job was to not fall apart under that volume and to reach each person before they scrolled away. It did that.

What we got wrong

Back to the content calendar reel.

PLAN was the wrong keyword.

Someone commented “this is literally the plan I needed, thank you” and the automation fired. They got a DM with our content calendar template in response to what was just a compliment. They replied asking what the message was about.

We apologised. Explained. They were fine.

But it sat with me. Because I do not know how many other comments we hit that I never even noticed. Someone having a perfectly normal conversation in the comment section, getting an automated DM mid-thought. We would never know who those people were.

We moved to a two-word phrase after that. The false triggers stopped.

The DM sequence was also wrong, but for a different reason.

On the second post we ran three messages in a row. First one delivered the resource. Second asked if they got it. Third offered something else.

Most people did not get past the first.

When I looked at the drop-off I understood why. Three messages from a page you just found does not feel like getting something useful. It feels like being subscribed to something. We cut it to one message, one link. The people who responded after that were people who actually wanted more.

The inbox situation

Back to that Monday morning.

About a third of the people who opened the DM replied. Questions about the template. Questions about the setup. A few asking if we did any consulting work.

They all needed a human response.

We had not assigned anyone to watch the inbox over the weekend. By Monday there were 60-plus open threads. Some still active. A few had gone quiet.

I do not know what we lost. That is the honest answer. I have no idea how many of those conversations would have turned into something if someone had been there on Saturday. That still bothers me more than any number in the dashboard.

What is different now

We still use it. The open rates alone make the setup worth it, and the Google reel settled any doubt about whether it could handle real volume.

What changed is one thing. Someone is assigned to the inbox on the day a comment automation post goes live. Morning check. Evening check. Two days after. Most of what comes in is easy. A few threads every time are worth being present for.

The tool does the volume. The conversation is still ours to have.

My team was spending 30 to 40 minutes every day pulling leads data and activity data from dashboards into one place. Different filters, different views, copy-pasting across tabs. Then that combined sheet went to the sales team, who uploaded it to the CRM.

Every. Single. Day.

Nobody liked it. Nobody questioned it. It was just the job.

The first thing that changed

ChatGPT launched. I started using it for content work — drafts, rewrites, captions. The obvious stuff.

Then one afternoon I described the data problem to it. Not asking for a solution, just thinking out loud.

It gave me a script.

I didn’t understand the script. I didn’t need to. I copied it, ran it, and it worked. Thirty to forty minutes became one click and twenty seconds.

I sat with that for a while.

What I actually learned

It wasn’t that AI was magic. It was that I’d been wrong about what required a developer.

I’d always sorted problems into two buckets: things I could solve myself, and things that needed engineering. The second bucket was basically everything technical. Scripts, bots, dashboards, any kind of automation. That whole bucket sat in a backlog. Sometimes it got prioritised. Usually it didn’t.

What I learned that afternoon: the bucket was wrong. I’d been filtering out entire categories of solutions before I’d even looked for them.

The thing that comes up most

Dashboards.

LSQ, Metabase, whatever the company’s running. They show you the data they want to show you. You want something different — a different filter, a different cut, day-wise instead of month-wise — and there’s no export. No API. Just a page that expects you to do the rest manually.

I’ve lost count of how many hours went into this kind of work. Not just me. Everyone in operations has a version of this problem. A dashboard that almost gives you what you need, and a gap between what it shows and what you actually want, that you fill with effort every single day.

The fix isn’t asking the data team for a new report. The fix is building exactly what you need in an afternoon.

What came next

I started describing problems instead of accepting them.

A Slack bot that pulled stats and posted them to the channel every morning. A script that checked a supplier page and sent me a message when the price changed. Small things, then less small things.

Some broke. Some needed three rounds of back and forth to get right. None of that mattered much. The cost of trying had dropped to almost nothing.

The two tools

Cursor and Claude Code. I use both, though the balance has shifted.

Cursor keeps everything visible. Good when you want to stay close to what’s being built.

Claude Code is just a terminal. Faster. Less to look at.

I used to use Cursor more. Now I’m mostly on Claude Code. Once you stop caring about the code itself, the terminal makes more sense.

The three things I’ve shipped

StoryDash — a dashboard that monitors story activity across 25+ Instagram pages, flags spacing violations, and sends hourly email reports to the team. I was spending 30 minutes every morning manually checking pages. Now I don’t open Instagram for this at all.

The daily OKR lead report — an email that lands before the first meeting, with every lead category ranked by urgency and projected month-end finish. The meeting went from 10 minutes of running numbers to actually making decisions.

Chrome extensions that pull data from dashboards with no export and no API. One click, data in clipboard. No Python workaround, no session tokens to maintain.

None of these went through an engineering backlog. None needed a ticket. I described what I needed and iterated until it worked.

What vibe coding means to me

Andrej Karpathy coined the term. Developers use it to describe writing code mostly with AI, barely touching it themselves.

That’s not quite what it means for me.

For me it’s the thing that happened when I stopped sorting problems into “I can solve this” and “this needs a developer.” It’s the realisation that the gap between seeing a problem and having something that solves it is now small enough that it’s worth trying every single time.

I’m not a developer. I run social media operations for a team spread across five languages. I know what a problem costs in hours and what it costs to just live with it.

What changed is I stopped living with things.

Every manual task I see now, I think: how long would it take to build something that just does this? The answer is usually a few hours. The break-even is usually a few days.

That’s the whole thing.

These aren’t just ideas. StoryDash is running in production, the OKR report lands every morning, and the Chrome extensions are in the browser right now.

More on this: Build Chrome Extensions Without Coding · Automate a Daily Lead Performance Report · Monitor Instagram Stories Across 25+ Pages

Numbers, live data, everything. Beautifully laid out.

No export. No API. Nothing. Just a page that shows you the data and expects you to manually copy it like it’s 2009.

I used to lose that fight. Copy, paste, format, repeat. Every single morning.

Now I just don’t.

The Python thing never really works

First instinct: write a Python script.

Hit the endpoint. Parse the response. Done.

Except internal dashboards don’t have public APIs. They load after a login. The data lives behind cookies and session tokens that only exist inside a live browser. So you get creative. Grab the cookies manually, pass them into requests, and it works. Once. Then the session expires and the script breaks. The auth flow changes and it breaks again. A rate limit gets added and now you’re debugging a hack at 9am before a meeting.

You spend more time maintaining the workaround than you ever saved building it.

I went through this enough times. It’s a dead end.

The thing that actually works

A Chrome extension doesn’t fake being a browser. It runs inside one.

Same session. Same cookies. Same page you’re already looking at. If the data is on your screen, an extension can read it. No tokens to replicate, no auth to reverse-engineer. You’re already logged in. The extension just reaches in and takes what’s there.

That’s the whole thing. Sounds obvious until it isn’t.

This is where vibe coding changed everything

I’ll be straight: I had no idea how Chrome extensions worked.

Manifest files, content scripts, service workers. There’s a whole structure to it. Enough that I never touched it.

Then I just described what I wanted to Claude Code:

“Build me a Chrome extension for this dashboard. There’s a table with the class .lead-metrics. When I click the extension icon, read every row and copy it to clipboard as CSV.”

Forty minutes later it was running in my browser.

Not a rough draft. A working extension doing exactly that, on a real dashboard, without filing a single ticket.

Forty minutes to build something that saves twenty minutes every morning. Break-even is two days.

What I’ve actually shipped this way

A metrics extractor that reads numbers off a locked dashboard. One click, data in clipboard, formatted exactly how my spreadsheet expects it.

A cross-tab aggregator. Seven regional tabs, each showing data for one region. I told Cursor:

“Open each tab, wait for it to load, grab the number inside .region-total, close the tab, then show me everything compiled in one place.”

Seven tabs of mental math became one button.

A form prefiller. Same ten fields, same values, thirty times a day. The extension fills everything predictable and skips the two fields that actually vary. Two minutes per form times thirty forms is an hour back every single day.

A page monitor that checks a supplier site on a schedule, saves the values, and tells me when something changes. No API on their end. Doesn’t matter.

None of these needed me to know JavaScript. Every one of them started with a plain description.

The prompt is the skill

This is what people miss about vibe coding.

Claude Code and Cursor aren’t magic. They need a clear description. The better you explain the problem, the better the first output. Vague in, broken out.

Three things I always include:

The URL or type of page. The exact element holding the data (right-click anything on the page, hit inspect, find the class name). What I want done with the data after.

That’s it. First version gets maybe 80% right. Two or three corrections and it’s done. The whole process feels less like coding and more like explaining something to a very capable person who just needs the specifics.

Claude Code is what I use when I want to describe the whole problem at once and get something fast. Cursor is better when I want to see the files, read through what it built, and tweak things myself. Both work. Pick one and just start.

How I think about problems now

Before this, hitting a data wall meant looking for workarounds. Is there a hidden export? Can someone from the data team pull this? Is there a third-party tool that connects?

Now the first question is: can I see it on a screen?

If yes, I can have something built today.

That shift matters more than any specific extension I’ve made. Problems that used to sit in a backlog somewhere now take an afternoon. Needing an engineer, waiting on a ticket, hoping someone has bandwidth — that’s just gone for this type of problem.

Anyone can do this. You don’t need to code. You need to know what you want and be specific about it.

The extension does the rest.

Same pattern — automated the daily OKR lead report that sends before anyone asks for it, and built an Instagram story monitoring dashboard that catches spacing violations I never knew were happening. Different problems, same approach.

More on this: What Vibe Coding Means for Non-Developers · Automate a Daily Lead Performance Report · Monitor Instagram Stories Across 25+ Pages

A room full of people in a meeting. The performance dashboard is open. So is a Google Sheet. Someone is running quick calculations, a spreadsheet here, an AI tool there, trying to get to the number fast enough to be useful.

Everyone is trying. Nobody is deciding yet.

This was the opening of every lead generation review. Smart people doing their best with what they had, and still spending the first ten minutes of every meeting running numbers instead of making calls. That’s not a people problem. The system just wasn’t built for it.

The answers always came. But they always came late.

That wasn’t the worst part.

The data was already old

The dashboard pulled numbers till the previous day. Data for today wouldn’t show up until after midnight. So every morning meeting — the one where you’re supposed to course-correct before the day gets away from you — was running on information that was already hours old by the time anyone looked at it.

We were doing real-time math on yesterday’s numbers. And acting like that counted.

I’ve been running social media operations long enough to know what a real-time decision feels like, and what a delayed one costs. A lead category tracking at 65% on Day 10 is recoverable. The same category at 65% on Day 25 isn’t. The window to act matters. And every morning we were showing up to the window hours after it opened.

The thing nobody says out loud

Nobody says this out loud. Someone has to be the one who knows the numbers. They’re always slightly under pressure to have them ready. They open the sheet, run the figures, try to remember which POC owns which category, and present while everyone else waits.

That person’s job in that moment isn’t strategy. It’s data retrieval.

Data retrieval is a computer’s job.

Say you have 25 active lead categories. Each with a different owner, a different monthly target, a daily run rate that shifts as the month progresses. Now someone has to walk into a meeting and have all of that calculated, current, and ready to present. Every single morning. The calculation is doable — but doing it manually, before a meeting, under time pressure, is a design failure dressed up as a routine.

I started thinking about what the meeting would look like if everyone already knew the numbers before they walked in.

What I actually needed

Not a better dashboard. We had a dashboard.

The problem wasn’t visibility. It was the gap between data existing and data being useful. Processed, ranked, delivered to the right people before they need to ask for it.

I wanted one thing: an email that lands every morning before the first meeting. Not a data dump. A briefing. The kind a sharp analyst would prepare — except it shows up automatically, every single day, whether anyone remembers to ask for it or not.

Which categories are bleeding. Who owns them. How far behind. Where they finish if nothing changes today. In that order, by urgency. Not alphabetically. Not by team. By how badly they need attention right now.

That’s it. The whole idea. Completely obvious once you say it out loud. Completely missing from how we were actually operating.

Building it

I built the whole thing with Claude Code. No data team. No engineering backlog. Just a clear problem, a clear output, and enough iterations until it worked.

The logic isn’t complicated once you write it down. Take the data. Calculate how each category is performing against where it should be on this specific day of the month. Not the monthly target, but the expected pace right now. Rank by gap. Flag the owner. Project the finish. Send every morning before the day starts.

What took time was getting the projections right. Not just “you’re behind.” More like: “at this pace, you’ll finish at 71% of target by month end.” That number is what changes a conversation. It turns “we’re a bit behind” into “we will miss by this much unless something changes today.”

That specificity is what makes people act. Vague warnings get noted. Precise consequences get addressed.

What the meeting looks like now

People walk in already knowing.

The email is already there when the day starts. Everyone’s seen it. The categories that need attention are identified. The POCs already know they’re flagged. Sometimes the problem is already being addressed before the meeting starts.

The meeting became what it was always supposed to be. People making calls, not running the numbers.

The data still updates at midnight. That part didn’t change. But the gap between numbers existing and the team being ready to act on them collapsed to nothing.

That’s the only gap that actually mattered.

More on this: Monitor Instagram Stories Across 25+ Pages · Build Chrome Extensions Without Coding · What Vibe Coding Means for Non-Developers

Same approach, different problems — Chrome extensions that pull data from locked dashboards and an Instagram story monitoring system that runs without anyone checking it.

Open Instagram. Check page one. Stories posted? Good. Check page two. Stories? Yes. Check page three…

Twenty-five pages later, thirty minutes had passed. And I hadn’t done anything useful. I’d just confirmed that things existed.

That’s not monitoring. That’s just time disappearing.

This post covers how to monitor Instagram story activity across 25+ pages without opening the app — including how to catch story spacing violations that quietly hurt reach, how to build an internal Instagram story analytics dashboard, and how to set up automated hourly email reports. Built entirely with Claude Code by someone running content operations, not engineering.

The problem I didn’t know I had

When you’re managing 25+ pages, there’s an issue that doesn’t show up anywhere: it’s not whether you post stories. It’s when.

Stories posted too close together don’t get distributed the way you’d expect. The algorithm sees a burst, not a cadence. Reach drops. Views thin out. And because you can’t manually track gaps across that many pages, it just keeps happening quietly.

We were posting stories two minutes apart on some pages. Sometimes one minute. We had no idea.

So I built StoryDash — an Instagram story monitoring dashboard

StoryDash is an internal Instagram monitoring dashboard that tracks story activity across multiple pages in one view, flags story spacing violations in real time, and sends automated hourly email reports — all without opening the app.

An internal dashboard. One screen. Every page, every story posted today, when each was last active, and whether the spacing is within the safe window.

37 pages. 96 stories today. 21 pages active. The ones with nothing posted and the ones breaking spacing rules, right there, without opening Instagram once.

Catching Instagram story spacing violations automatically

When I added the spacing check, I expected maybe two or three pages with issues.

It was more than that. Multiple pages posting consecutive stories less than a minute apart. Some flagged critical. This had been happening every single day and we’d never caught it.

I showed this to the team. Nobody spoke for a second.

Per-page Instagram story analytics: timestamps, thumbnails, and spacing

Click any page, see the full day: thumbnails, timestamps, exactly where the gaps are too short.

Three pairs of stories posted under 30 minutes apart. Worst gap: 0 minutes. The dashboard shows the exact violation and the recommended minimum, so the person managing that page knows what to fix, not just that something’s wrong.

The email that arrives without anyone asking

The dashboard solved the need to check. But I wanted to remove the need to check the dashboard too.

Hourly automated email. Every hour: pages that posted, pages that haven’t, which ones need attention.

93 stories tracked. 23 pages posted. 8 with nothing yet, highlighted.

The information arrives. No one has to open anything.

How I built an Instagram monitoring tool with Claude Code (no engineers)

Built with Claude Code: dashboard, spacing logic, automated emails, all of it.

The process was: describe the problem in plain language, see what gets built, describe what’s wrong or missing, iterate. No ticket raised. No engineer looped in. No technical spec written.

I started with the core problem: I need to see story activity across all pages in one view. Claude Code built the dashboard. Then spacing detection: flag anything under 30 minutes between consecutive stories. It added the logic and the violations view. Then the email report: send this data hourly, formatted cleanly. Done.

Three features. One clear problem statement each time. The whole thing went from idea to running in production without once opening a code editor.

I manage content operations. Building tools is not a skill I have. That’s the point.

Running in production. Full project overview: StoryDash →

What you need to build an Instagram story monitoring tool

The foundation is the Instagram Graph API — Meta’s official API for accessing story data from pages you manage. To use it:

• A Facebook developer account and an approved app
• Instagram Business or Creator accounts (personal accounts have no API access)
• Page access tokens for each account you want to monitor

The API returns story media objects with timestamps. From there, the spacing logic, the dashboard, and the email report are all built on top of that data.

Most teams don’t have this. Not because it’s technically hard. It just requires an engineer to set up and never gets prioritised against product work. Claude Code removes that dependency entirely.

How to monitor multiple Instagram accounts at scale

The pattern works whether you’re building your own tool or evaluating options. Four things you need:

1. A single data source for all pages Pull story data via the Instagram Graph API — timestamps, media count, last activity per page. If your data lives in separate places (or only inside the app), you’ll always be checking manually.

2. One view across all accounts All pages, story counts, last active time, and posting status in a single screen. The moment you have to click into individual pages, the system breaks down at scale.

3. Automated spacing checks Set a minimum gap threshold (30–60 minutes is the safe range). Flag anything under it automatically. Without this, spacing violations happen silently every day. You only find out when reach drops.

4. Proactive reporting Information should find you, not the other way around. Scheduled email reports (hourly or daily) mean the team always knows the status without anyone opening a dashboard. If you’re still pulling the data yourself, you’ve built a lookup tool, not a monitoring system.

StoryDash was built around these four. But the architecture applies to any Instagram monitoring setup at scale.

Does posting Instagram stories too close together hurt reach? Yes. Stories posted within minutes of each other are treated as a burst by the algorithm, not a cadence. Reach and views thin out. A minimum gap of 30 to 60 minutes between stories is the recommended safe window for consistent distribution.

How do you monitor Instagram story activity across multiple pages without opening the app? Build a dashboard that pulls story data and displays post times, gaps between stories, and pages with no activity in one view. Pair it with automated email reports so the information arrives on a schedule rather than requiring anyone to check manually.

Can you build internal social media tools without a developer? Yes. Claude Code lets you go from a clear problem description to a working internal tool without engineering resources. StoryDash was built this way: dashboard, backend logic, and automated reports, by someone managing content operations.

What is the best tool to manage multiple Instagram pages at once? A custom internal dashboard built around your specific pages beats any generic third-party tool for teams managing 25+. Most third-party tools focus on scheduling, not monitoring. The real gap is real-time visibility — knowing which pages have posted stories today, which haven’t, and whether story frequency is within safe limits. A tool like StoryDash solves this because it’s purpose-built for your workflow, not a broad audience.

How do you track Instagram stories across multiple accounts? The reliable way is to pull story data via the Instagram Graph API into a single dashboard, showing all accounts in one view with timestamps and activity status. This removes the need to manually open each account. Pair it with automated reports sent on a schedule so the team always knows the status without checking.

What is Instagram story spacing and why does it matter? Story spacing is the time gap between consecutive stories on a single page. When stories are posted too close together — under 30 minutes — the algorithm treats it as a burst and reduces distribution. Each story gets fewer views than it would with proper spacing. At scale, across many pages, this happens constantly and silently unless you have a system that tracks and flags it.

How do you manage Instagram content operations at scale? Content operations at scale means replacing manual checks with systems that surface the right information automatically. For Instagram specifically: a monitoring dashboard that shows story activity across all pages at once, automated alerts for spacing violations, and scheduled email reports that deliver status updates without anyone needing to open a dashboard. The goal is to make the team’s default state informed, not reactive.