Developer Experience Is a Product Decision
My wife is a social media creator. She posts regularly across platforms and gets comments, but keeping up with what those comments were actually saying was becoming a real task.
So she asked me if I could build something. That's when I found out the hard way that developer experience is a product decision.
What questions kept coming up? What content ideas were hiding in the comments? What did her audience actually want to see next? She'd been paying an assistant to handle this manually. The problem wasn't the cost, it was the output. Summaries were inconsistent, things got missed, and the signal she needed kept getting lost in the noise.
I should mention: I'm not a developer. I've never written production code. But AI coding tools meant I could describe what I wanted and get working code back. So I built a small web app that connects to her Instagram, pulls recent posts and comments, and sends them to Claude to generate a structured digest. Recurring themes, questions worth responding to, content ideas the audience was signaling, overall tone. One button, one report.
The Claude part took about 30 minutes.
The Instagram part took hours.
A Maze With Two Entrances
I want to be fair here. The restrictions I ran into aren't arbitrary. There's a history behind why platforms tighten API access, and it's not hard to understand. The gates exist for real reasons.
For context, I'd integrated other tools without much friction along the way. Giphy, Cal.com, Web3Forms. The docs were clear, the steps were sequential, and something worked at the end. That's the baseline I was working from.
What I ran into wasn't the gates. It was that no one told me which door to use.
There are two completely different ways to access Instagram data through Meta's API, and the documentation doesn't make it obvious which one applies to your situation. I spent a significant chunk of time on the wrong path before I figured out the other one existed. Each path has different requirements, different setup steps, and different limitations that aren't clearly surfaced upfront.
The frustrating part wasn't any single requirement. It was that the feedback loop was nearly nonexistent. When something didn't work, I couldn't tell if I was close and missing a small detail, or entirely in the wrong place. That uncertainty is expensive when you're learning as you go.
Who's Showing Up Now
I'll be honest: I don't know exactly why these APIs exist. There are probably good reasons that have nothing to do with people like me. But they're there. And what's changed is who's showing up to use them.
The barrier to building has dropped enough that a new wave of people are attempting things that weren't realistic a few years ago. Not engineers with years of context, but people with real problems and AI tools that can handle the code. That pool is only growing. And whether or not these platforms designed their APIs for that audience, the opportunity is sitting right there.
The gates can stay. But the path through them needs to be legible for the people now standing at them. When the hardest part of integrating two tools is the one without a business model attached to it, something is off.
Where It Landed
The app is built. The Claude synthesis is solid. The dashboard is clean. But I still haven't been able to confirm the core feature works end-to-end, because getting to a clean test required so many prerequisite steps that I never got there with confidence. That's where it sits.
It's not that I gave up. It's that the validation kept moving. Each fix revealed another requirement I hadn't anticipated, and at some point the cost of continuing to chase it outweighed the signal I'd get from the test.
The idea was the easy part. The AI was the easy part. The access layer was where the hours went.
That feels like something worth fixing.