Handled – AI Social Media Manager
I had been long told that I have great products but the only thing holding me back is that they lack social media presences. I enjoy being behind the scene building products and always found social media being a huge burden. So I thought, what if I automated the social media of my different projects in a way that I would just have to feed seed ideas and let the automation learn the direction to take by creating finalized posts adapted for the different social media platforms. Along the way, I thought this could be useful to many other founders who either lack time and prefer spending their energy on their product itself due to priority reasons and other urgencies, while still making their products heard about by the world. Hence I ventured into the route of productizing the initial idea into an AI powered social media automated platform.
My Role: End-to-End Development and Leadership
Like my other platforms, I wore the hat of product owner and developer. In this end-to-end role, I was responsible for everything from initial concept and architecture to full-stack programming and interface design. The tech-stack behind it is React-Native for Android and iOS apps; for the website which has many of the mobile apps features, the tools and languages were React and Typescript; with backend service and API with use of Python and FastAPI.
Core Functionality Highlights
With the perspective of augmenting the user experience, Handled has some notable features:
-
Posts creation with brand voice and visual style: Handled can created weeks of posts and with option of multiple posts per day in the same wording and visual style of the brand.
-
Always ON Agent: Handled comes with an AI agent server instance ready to take on tasks 24/7.
-
Agent that learns and improves posts: Handled will learn from your feedbacks and improve future posts.
Challenges
Ensuring seemless authentication experience
The problem
I wanted users of our AI social media agent to have a genuinely frictionless experience. When someone uses the website or installs the app and takes a subscription, we automatically provision them a dedicated Linux agent instance that acts on their behalf against our orchestration backend, creating posts and managing connected accounts. But even a user who never left our app still had to go through a separate browser flow, open a link, sign back in, click approve, purely so our backend could confirm who they were and which workspace belonged to them.
Working through it with AI
– I brainstormed a fix with an AI coding agent. It proposed a server-to-server credential handoff and presented it as complete. I wasn’t convinced, so I had it critically audit its own idea, which surfaced real gaps: no way for the user to see or deny the action, a spoofable trigger, no revocation policy.
– I pushed further and asked whether we already had something like a secure credential mechanism for an agent instance in our own codebase. That sent it back into code it had been working in all session, where it found an existing endpoint it had overlooked. Pointing it to a specific internal planning doc surfaced a near-identical design that had been scoped before and shelved, blocked on one unconfirmed question about our infrastructure provider.
– Rather than let it keep reasoning in the abstract, I had it verify that exact capability against the provider’s live documentation. Confirmed: a secret can be securely injected straight into an agent instance’s environment at creation, never exposed to the client or the model.
– When it drafted the implementation plan, it defaulted to fully replacing the old verification system. I caught that too: some users run their own self-managed agent instances and still need that flow, so it had to stay as a supported path, not get deleted.
The result
A validated design that removes the extra login step for the common case, while keeping the original flow intact for users who self-host their own agent. Grounded in verified fact, not just a plausible-sounding idea.
Simulation tests using AI
I created a test simulation environments where AI agents are used to imitate user behaviors across various possible scenarios to be able to test functionalities before they are made available to users. This is an idea that I had as I was working on the project and I’m really proud of. It comes with great benefits such as finding if the new features will work as expected before deployment to real users, or if already existing features are still working even after adding new features or making code changes. Such test environment is setup in a way that AI agents are configured and prompted in a way to make certain human choices that would come from the Handled app, through the AI social-skills which then uses the API for service requests.
End notes
Building Handled end-to-end sharpened how I think about automating something as trust-sensitive as a brand’s voice and social presence: the AI has to be right, not just fluent. Social media automation only works if it doesn’t feel automated, and that starts with treating every AI-generated decision, from image to caption to the architecture running it, with the same scrutiny. Handled is my proof that AI can run a brand’s presence without losing its voice.