I Removed AI Content Generation from My Social Media Product

I removed AI content generation from PostSider. Image generation, video generation, slides, voice, autopost, an internal copilot, and an inherited agent stack all went away. I kept two narrow AI actions: review a draft and rewrite a caption. The product became easier to explain, safer to operate, and more useful for the job I originally wanted it to do: publish social media content reliably.

The decision sounds backward in a market where adding AI to every screen is treated as progress. It was still the right decision. Content generation was the easiest part to demo and the least important part to own.

The product looked richer and felt less focused

The inherited AI surface made the feature list longer, but it did not make the publishing workflow clearer. Every generated asset created another path that could fail before a post even reached the queue.

The old surface included ten feature groups:

• a LangGraph agent and its bridge;
• an internal chat and tool server;
• a copilot;
• autopost;
• AI image generation;
• AI video generation;
• AI slide generation;
• voice generation;
• a settings surface for the agent stack;
• single sign-on into a third-party media service.

It looked impressive in a demo. In the codebase, it meant multiple vendors, API keys, billing relationships, callback paths, settings screens, and database models. The media features alone brought dependencies on fal, Veo, and HeyGen. A failure in any one of them became my support problem even though none of them made a scheduled post more likely to reach its destination.

That distinction became impossible to ignore. PostSider is responsible for the path from an approved draft to a real social account. The hard problems live in account permissions, platform-specific payloads, token refresh, media processing, timing, retries, and partial failures. An image generator did not remove any of those problems. It sat in front of them.

Generated content had become the commodity layer

A social media product does not need to own generation to accept generated content. Users already arrive with text, images, videos, and tools they prefer.

Some users write directly in the composer. Others bring content from an editor, an automation, or an AI agent. All of them need the same things after creation: choose the correct accounts, adapt the post to each platform, find a free slot, send it for review, and know whether it actually published.

Owning another generator forced PostSider to compete with every model and creative tool at once. Owning the publishing path gave the product one clear responsibility.

This also changed how I think about AI features. A built-in generator starts with a blank box and asks the product to invent something. A checker starts with the user’s work and asks whether it is ready. The second job has a boundary. It can point to a missing field, a weak caption, or a mismatch with the selected platform. The user remains responsible for the idea and the final decision.

That is why the two remaining AI features survived:

Post Checker reviews a draft before scheduling. It can evaluate the content for each selected platform and return specific issues.

Caption rewrite improves text the user has already supplied. It preserves the original facts while producing alternatives for a chosen platform or tone.

Both actions run through the same small provider interface. The current code supports a platform key or a per-organization key, and the feature returns an explicit configuration error when no provider is available. There is no hidden media-generation pipeline behind the composer.

Deleting AI meant removing its shadow

Removing a feature is rarely a file deletion. A feature leaves database models, enum values, configuration fields, routes, settings screens, icons, tests, and assumptions in code that never mention its name.

The first cleanup left orphaned Prisma models behind. AutoPost, AgentToken, and the mastra_* tables still existed even after their user-facing features were gone. Dead enum values and an organization-level mode flag remained too. They needed a dedicated migration instead of being left as permanent archaeology in the schema.

The same pattern appeared in the interface. Removing the agent required checking navigation, settings, onboarding, permissions, and every keyed map that expected the deleted feature to exist. Removing a media vendor required more than deleting an SDK. Environment variables, validation, callbacks, documentation, and deployment configuration had to disappear with it.

This was the most useful engineering lesson from the whole change: the cost of a feature is distributed across the system. A folder is only the visible part.

If you inherit a codebase, search beyond imports. Search the schema, environment templates, route registration, permission names, settings unions, analytics events, and migration history. A dead feature that still owns a table or secret is not fully dead.

The difficult part starts after the caption exists

Once generation was gone, the actual product work became obvious. A scheduler is a distributed system wearing a calendar interface.

A single post may target several external APIs. One platform can accept it while another rejects the media. A token can expire after approval but before the scheduled time. An upload can finish while the worker loses the response. A retry can repair the job or publish the same caption twice. The user still expects one simple answer: did my post go live?

Those are the problems I chose to own in PostSider:

• a shared calendar for human and automated workflows;
• drafts and approval before public actions;
• per-platform previews and validation;
• durable scheduling and token refresh;
• idempotent API requests for safe client retries;
• signed webhooks that close the loop after publication;
• a pause control when automation needs to stop.

None of those features produces a clever demo image. They make the difference between a tool someone tries and a system they can leave connected to a real account.

I wrote separately about the predictable places where AI agents fail at social media. Most failures happen around the content: API limits, timing, duplicates, approval gaps, and ambiguous delivery. The publishing layer has to contain those failures regardless of who wrote the caption.

The same principle applies to human review. Human-in-the-loop workflows do not have to become bottlenecks when the system separates preparation from the final public action. Automation can assemble the draft and schedule. A person can inspect the exact result and decide what leaves the system.

Removing features made PostSider easier to sell

Before the cleanup, explaining PostSider required explaining which AI generated what, which vendor powered each media type, and how the internal agent related to the scheduler. The explanation was longer than the user’s problem.

Now the pitch is shorter: bring the content, connect the accounts, and PostSider handles review, scheduling, and publishing. If an external agent prepares the work, it enters the same calendar and the same approval process as work created by a person.

That is the product I can improve without chasing every new model release. Better provider adapters improve every customer workflow. Better failure reporting reduces support. Better approval controls make both agencies and solo founders safer. Work on the publishing core compounds instead of becoming obsolete when a media vendor changes its API.

The narrower product is also more honest. PostSider does not claim to invent a strategy, understand an audience better than its owner, or replace editorial taste. It provides the operational layer between finished content and public social accounts.

For a solo founder, that focus matters more than a crowded feature grid. Every integration I keep becomes code I need to patch, secure, observe, and explain. Removing a feature is sometimes the fastest way to improve the product that remains.

What I would ask before adding AI again

I am not opposed to adding AI. I now require a clearer answer before it enters the product.

Does the feature make an existing publishing decision safer or faster? Can it operate on user-supplied content instead of creating another parallel workflow? Does it reduce work in the core path, or add a vendor beside it? Can I explain the failure state without blaming a model?

Post Checker and caption rewrite pass that test. They are bounded, optional, and attached to an existing draft. Full content generation did not.

The surprising part is that I expected PostSider to feel smaller after the deletion. It feels more complete. The product stopped trying to be the writer, designer, video studio, voice generator, and publisher in one interface. It became the place where finished work becomes an approved, scheduled, and observable publication.

That is the version now running at PostSider. It generates less content than it used to. It does a better job of getting the right content to the right account without taking the final decision away from the person responsible for it.

Lukasz Blania is the solo founder of PostSider, a social media scheduling and publishing platform for people and automated workflows.