How ProPost AI Turns LinkedIn Chaos into 365 Drafts a Year

Most LinkedIn content tools fail the same way. They generate one decent post, then drift. By the third or fourth draft, the tone is off, the structure is different, and the user is back to writing everything themselves. ProPost AI was built to solve that specific failure mode, producing LinkedIn content at the rate of 365 drafts per user per year without the quality degrading over time. That constraint shaped every architectural decision I made.

The real problem was prompt drift, not generation

The obvious assumption is that the hard part of an AI content platform is getting the model to write well. It is not. Any decent language model can produce one good LinkedIn post given a clear brief. The hard part is producing the two hundredth post in the same voice, with the same structural logic, for a user who set their preferences six months ago.

I called this prompt drift. Over a long session history, context windows fill up, system prompts get compressed, and the model starts averaging across all its training rather than staying anchored to the user's defined persona. The fix was not to write better prompts. It was to treat the user's voice profile as a first-class data object, stored separately, versioned, and injected fresh into every generation request rather than accumulated in a rolling context.

This meant building a persona layer that sat between the user interface and the model API. Each user's tone markers, preferred post structures, and topic clusters were serialised and stored. Every generation call loaded that profile from scratch. The model never saw its own previous outputs unless the user explicitly included them as examples.

Scheduling across multiple networks without API chaos

ProPost AI integrates with LinkedIn, Instagram, Facebook, and other major networks. Each of those platforms has its own rate limits, OAuth token lifecycle, and post format constraints. Managing that across a multi-tenant SaaS product is genuinely tedious if you do not architect it correctly from the start.

I built a queue-based scheduling layer that treated each network connection as an isolated worker. A post scheduled for LinkedIn went into a LinkedIn-specific queue with its own retry logic and token refresh cycle. A failure on Instagram did not block the LinkedIn worker. Each queue was independently observable, so I could see exactly where a delivery failed and why.

Token expiry was the most common failure mode in early testing. OAuth tokens for social APIs expire on schedules that vary by platform and by user activity. I added a proactive refresh job that ran ahead of expiry windows rather than waiting for a 401 to trigger a retry. That alone eliminated most of the silent scheduling failures that plagued the first version.

Image generation had to be constrained to be useful

The platform includes image generation alongside copywriting. The temptation with image generation is to give users maximum freedom. Every parameter exposed, every style available, full creative control. I tried that. Users did not use it.

The problem was decision fatigue. A user who needs to post three times a week does not want to configure an image generation pipeline each time. They want something that looks consistent with their brand and is ready in under thirty seconds. I reduced the interface to a small set of brand-anchored style presets, each tied to a generation prompt template that had been tested for LinkedIn's image aspect ratios and visual density norms.

The result was faster generation and higher usage. Constraining the options was the right engineering decision, not a compromise.

Keeping the AI layer swappable

One decision I made early and do not regret: I never called any model provider's API directly from the application layer. All model calls went through an internal abstraction that I could swap without touching product code. This mattered because the model market moved fast. A provider that was the obvious choice when I started building was not necessarily the right choice six months later.

This pattern shows up in other products I have built. On Fursa, the visa route eligibility engine, the same abstraction let me run different models against different classification tasks without rewriting the surrounding logic. On Job Hunter, it meant I could test generation quality across providers without a full deployment cycle. Keeping the AI layer thin and swappable is not clever architecture for its own sake. It is basic risk management in a market where provider capabilities and pricing change quarterly.

What I would do differently

The persona versioning system worked, but it was more complex than it needed to be at the start. I built a full versioning schema before I had evidence that users would actually iterate on their voice profiles. Most users set a profile once and never change it. A simpler append-only log would have been sufficient for the first year, and I could have added branching later if the data showed users needed it.

I also underestimated the support burden of multi-network OAuth. Every platform has its own quirks, and when a user's linkedin token expires silently, they do not know whether the problem is the platform, the app, or their own account settings. I eventually added a connection health dashboard that surfaced token status per network, which reduced support tickets significantly. I should have built that in the first sprint, not the fourth.

The scheduling architecture, the persona layer, the constrained image interface, these were the right calls. The over-engineered versioning and the delayed observability tooling were the wrong ones. Both are worth knowing if you are building something similar.

The engineering is documented if you want to look closer

ProPost AI is one of several AI products I have built at Dinovix. The full case study covers the metrics, the stack, and the decisions in more detail. If you are assessing whether the work is real, that is the right place to start.

If you are building something in this space and want a technical conversation about architecture, rate limit management, or AI abstraction patterns, the engineering lens covers how I approach that class of problem. Or if you would rather ask directly, Kadon AI can answer from the full record without a meeting.