Autonomous content for indie devs — how the brain loop works

When we describe SuperPost in a sentence, we say "marketing on autopilot for indie devtools." When we describe it in a system, we draw five boxes connected in a circle. Those five boxes are what we call the brain loop — the closed system that takes signals from your codebase, produces native content per platform, and improves itself every time something ships.

This post is the engineering walkthrough. If you've used the product and wondered what's actually happening behind the scenes when a git push becomes a TikTok at 9:14am, this is the answer.

The five-box diagram

   ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
   │  Sense   │ -> │  Plan    │ -> │  Render  │ -> │  Publish │ -> │  Learn   │
   └──────────┘    └──────────┘    └──────────┘    └──────────┘    └──────────┘
        ^                                                                 │
        └─────────────────────────────────────────────────────────────────┘

That's the whole thing. The cycle runs continuously per workspace, with no required human input after the initial onboarding. Let's go through each box.

1. Sense — pulling signal from your codebase

The first job is to know what's worth talking about. We watch four streams of signal per workspace:

• Git activity. Every push to a tracked branch, every release tag, every merged PR with a marketable label.
• Issue tracker. Closed issues with high engagement (comments > 3, reactions > 5). These are usually the things real users care about.
• Product analytics. Posthog/Plausible events that hit thresholds — first 100 active users on a feature, a usage spike, a retention milestone.
• External proof. Hacker News mentions, Show HN posts, Reddit discussions, X posts that tag the product. These get amplified.

The sense layer is, deliberately, dumb. It collects signals, attaches metadata, and hands them off. It doesn't decide what's a good story — that's the next box's job. We learned this the hard way after our first version tried to be clever at this step and missed obvious wins because the heuristics were too narrow.

2. Plan — deciding what's worth saying

The planner is where the magic, such as it is, happens. It runs every six hours per workspace and answers a single question: given everything that's happened in this codebase, what are the three best stories to tell this week, and on which platforms?

To answer that, the planner has access to:

• The signal queue from the sense layer. Ranked by recency and weight.
• Brand voice memory. A vector index of how this specific founder talks about their product — their typical phrasing, what they've called out as off-limits, the angles they've used before. (We go deep on this in Brand voice cloning — the privacy story.)
• Platform performance history. What hooks have worked on TikTok for this account vs. LinkedIn vs. X, scored by engagement rate.
• Content calendar state. What we've shipped this week, what's queued, what gaps exist.

The planner outputs a draft schedule: "Tuesday 9am, TikTok, hook style 'curiosity-question', topic 'the new --watch flag', estimated runtime 47s." Each entry is a small JSON record that the rendering stage will turn into actual content. Crucially, the planner doesn't write copy. It produces intent. Decoupling intent from rendering is what lets us swap render strategies without touching planning logic — and what lets us A/B test rendering approaches without confounding the upstream planning signal.

3. Render — turning intent into native content

This is the largest part of the system by code volume, and the part most marketing tools get catastrophically wrong. The render layer takes a single intent record and produces six outputs — one per supported platform — each one engineered to feel native to that surface.

A LinkedIn render is a 1200-character text post with a specific cadence: a slow-roll opening, a personal story, a takeaway. A TikTok render is a 30–60 second vertical video with on-screen captions, a hook in the first 1.2 seconds, and a payoff frame in the last 3. An X render is a thread of 4–7 posts, each under 280 characters, opening with a contrarian frame.

We don't share copy across platforms. We don't even share the outline across platforms. Each render is a separate model call with platform-specific prompting, platform-specific examples, and platform-specific quality gates. The text engines are LLMs (Sonnet 4.6 for most, Opus 4.7 for harder strategy work). The video engine is a stack we built on Modal — covered in detail in Inside the render pipeline.

Every render also produces a C2PA provenance record — a cryptographically signed manifest declaring "this content was produced by an AI engine, here are the source signals, here is the model lineage." We embed it in every output. The why and how are covered in C2PA provenance on every AI render.

4. Publish — six platforms, six adapters

Once the renders are done, the publish layer takes over. We have six native adapters: TikTok, Instagram, YouTube Shorts, X, LinkedIn, and Reddit. Each adapter is its own service. Each one knows the API quirks, the rate limits, the optimal posting windows, the metadata schema.

We ship via the platform's native API where one exists (X, LinkedIn, Reddit), and via mobile-app-server protocols for the ones that don't expose proper APIs (TikTok, Instagram). Adapters are stateless — they take a render artefact and a target account, and they return a published post ID or a structured failure. State lives in our publisher service, not in the adapters themselves.

This separation matters because platforms break adapters all the time. When TikTok shipped a breaking change to their internal protocol in March, we had a working fix in production within 11 hours. The fix touched 240 lines in the TikTok adapter and zero lines anywhere else. That's the value of clean boundaries.

5. Learn — closing the loop

The last box is what makes the system get better instead of staying static. Every published post produces a performance record — initial engagement velocity (first 30 minutes), 24h engagement, click-through to the product, follow conversions, and any direct attribution we can capture.

Those records flow back into three places:

• The brand voice index. Posts that overperformed get higher weight in future voice retrieval. Posts that underperformed get downweighted. The index drifts, slowly, toward what's actually working for this account.
• The hook performance table. We score each opening line against engagement, segmented by platform and account vintage. Hooks that hit a 90th-percentile-or-better engagement rate get promoted. Hooks that bomb get retired.
• The planner heuristics. Aggregate patterns — "we shipped three engineering deep-dives this week and engagement is dropping" — feed back into next week's planning. The planner explicitly tracks variance and pushes for diversity when content gets too monotone.

This feedback loop is the single biggest reason SuperPost outperforms the static-prompt content tools you've seen elsewhere. After 90 days on a workspace, the engine is producing content that is measurably better-tuned to that specific audience than anything you'd get from a one-shot AI marketing tool. We've measured this; we'll publish the numbers later this quarter.

What you don't see

Wrapped around the five-box loop is a lot of unsexy infrastructure: a queue with deterministic retry semantics, a per-workspace budget cap, a content moderation gate that runs before any post leaves our network, a draft-mode flag for new accounts, a kill switch that pauses an entire workspace if engagement collapses (so we don't keep posting into the void).

None of it is glamorous. All of it is what makes the loop run for months without human attention. That's the whole product.

See it work on your repo

If you've made it this far, the obvious next step is to book a 15-minute demo where we connect a sandbox workspace to your repo and walk through what the planner would queue for your project this week. We don't post anything live — it's a dry run on real data.

If you'd rather just read along, the newsletter goes out roughly weekly, and the changelog covers every release with a short commentary on what changed and why.