The problem
Scheduling Instagram posts as a solo operator is a solved problem if you are willing to pay team pricing for it. Every tool I looked at was built for a marketing department: approval workflows, seat-based billing, analytics dashboards nobody reads. I wanted a queue and a calendar.
So I built one. That is a good reason to start a project and, as it turns out, not the same thing as a reason to finish one.
How we approached it
Built end to end rather than assembled from services. Authentication, the scheduling queue, media upload and processing, the publishing pipeline against Meta's Graph API, and an admin layer to run it all.
The interesting constraint was Meta's platform. Publishing to Instagram on someone's behalf means app review, defined permission scopes, and behaviour that has to match what you told them it would do. That shapes the architecture from the beginning, you cannot bolt compliance onto a publishing pipeline afterwards.
The rest was ordinary discipline: queue state that survives a failed publish, media handling that does not fall over on large uploads, and an admin view honest enough to show what actually happened rather than what was meant to happen.
What the visitor sees
What the owner sees
Built with
What I'd do differently
This one taught me more by not becoming a business than the ones that worked.
I built the whole utility to solve my own problem, and engineered in a way that it would help others too. Solving your own problem is a genuinely good place to start, the doesn't necessarily mean there would be a demand for it.
Meta's app review is a hard dependency you can't schedule around. I left it until the product was finished, which meant a completed application sitting still, waiting for someone else's queue. That should have been started in parallel, early, even in a rough state.
Then I audited my own work. It turned up several medium and low severity issues, nothing that broke anything, nothing exploited, but things I would want closed before asking someone to trust the tool with access to their accounts. Writing that on a public page is uncomfortable. It is also the only honest answer to "how do I know your code is secure?" The answer is that I check, and I will tell you what I find. Anyone who says they have never found anything in their own work has not looked.
So I stopped. Continuing would have cost the thing I actually care about building, and a finished product nobody asked for is more expensive than an unfinished one. Knowing when to stop turns out to be a skill, and I would rather show you the project where I learned it than pretend it did not happen.