Why we're building SuperPost — the founder story

I have a folder on my laptop called archived-repos. It has 47 directories in it. Each one is a developer tool that someone I know personally built, shipped, talked about for two weeks on X, and quietly walked away from. They are, on the whole, better products than the ones that won.

That folder is why I'm building SuperPost.

The pattern that broke me

The first archived repo in that folder is mine. It was a Postgres migration tool I shipped in 2019. It was, objectively, faster and safer than the dominant option at the time. I posted about it three times on Twitter, wrote a launch blog post nobody read, got 31 stars, and gave up.

Two years later I joined an infra startup as employee #4. The product wasn't better than mine had been. But the founder spent three hours every morning posting on LinkedIn, recording loom videos, writing threads. By the time I left, the company was at $4M ARR. The CEO told me, candidly, that he hated every minute of the marketing — he just understood that building the product was 30% of the job.

That broke something in my head. Because the thing he was doing — the morning content shift — was, structurally, automatable. Not the taste. Not the strategy. But the mechanical loop of "take a thing that happened in the codebase, turn it into six native posts on six platforms, learn from what landed, do it again tomorrow" — that's a workflow. Workflows can be automated. We've spent twenty years automating the workflows of every other knowledge worker. Why is the developer-marketer the last one doing this by hand?

The honest answer

The honest answer is that nobody who could automate it wanted to. The developers who could build a content engine were, almost without exception, the ones who would rather be writing the next migration tool than thinking about TikTok algorithms. The marketers who understood the loop didn't have the engineering taste to build it well. So we ended up with a market full of "AI marketing" tools that were, charitably, terrible — bolt-on Buffer clones with a GPT wrapper, scheduling tools dressed up as automation, content factories that produced average slop at industrial scale.

None of them solved the actual problem, which is: the inputs cost too much.

A founder doesn't have time to write copy. A founder doesn't have time to sit through a video shoot. A founder definitely doesn't have time to go figure out which of seven platforms a particular hook will work on. So the moment any tool requires those inputs — even small ones — it falls back into the "thing I'll get to next week" category, and joins the archived-repos folder.

The only durable solution is: inputs are free. We can't ask a developer for copy. We can't ask for video footage. We can't even ask which platform to post on. The only input we get is the input they're already producing — git push, a release tag, a closed issue, a Linear ticket update. Everything else, we generate.

That's the thing I couldn't stop thinking about for two years.

What had to be true to make it work

I knew from day one that the product was straightforward to describe and ferociously hard to build. Three things had to be true simultaneously:

1. Content quality has to clear the "wouldn't be embarrassing" bar.

The bar isn't "as good as a human marketer." The bar is "the founder wouldn't unsubscribe from their own brand if they saw this on their feed." That sounds low. It isn't. Most AI-generated content fails that test by the third sentence. We had to engineer for taste, not just throughput. That meant building a render pipeline that does multi-pass refinement, brand-voice cloning that captures the specific cadence of how you talk about your product, and a hook engine trained on what actually converts for developer-tool audiences specifically — not generic marketing data.

2. The model has to learn forever.

A static prompt is a slowly decaying asset. The first month a tool ships, the prompts are tuned. By month six, the platforms have shifted, the audience has gotten saturated, and what worked in January doesn't work in July. The only way out is a feedback loop where every post produces a labelled training signal — engagement, click-through, follow-conversion — and the engine gets sharper over time. We went all in on this from week one. By the time you've been on SuperPost for three months, the engine knows what hooks land for your specific audience, in a way no static system ever could.

3. Distribution has to be native, not cross-posted.

The single biggest tell of a marketing tool that doesn't get developers is when it cross-posts the same text to TikTok, LinkedIn, and X. A TikTok hook is a question that creates urgency in three words. A LinkedIn hook is a story that earns a slow scroll. An X hook is a contrarian punch. Same idea, three completely different surfacings. If you don't render the variant for each platform, you're producing six bad posts instead of six good ones.

We built six native adapters from scratch. Not a shared "post" abstraction with platform-specific overrides — actual, bespoke renderers per platform. It was more work than the rest of the product combined. It was also the thing that made the output not-embarrassing.

What I got wrong

A non-trivial amount, honestly.

The first version of the product asked the user to approve every post before it went live. We thought this was a feature — humans in the loop, control, safety. It turned out to be the bug. The whole point of automation is that you don't think about it. The moment you ask a founder to log in once a day and approve a queue, you've recreated the original problem at smaller scale. We've since flipped the default: posts ship autonomously, you review the analytics, you flag what missed.

The second version had a free tier. We thought that's how developer tools were supposed to work. It turned out the free tier attracted a population of users who couldn't afford the model spend they generated, didn't convert, and tied up our support hours with edge cases. Worse, it sent a price signal that conflicted with the actual value of the product. We removed the free tier and our quality of pipeline went up by ~3x within a month.

The third version had a "AI dashboard" that showed users what the engine was thinking. I was very proud of it. Nobody used it. Nobody wanted to. The job-to-be-done was "make my marketing happen," not "look at how clever the system is." We deleted the page, freed up a quarter of engineering bandwidth, and shipped two more platforms instead. That's the whole job.

What's next

This blog will be the place where we write down what we're learning. Engineering deep dives, customer post-mortems, occasional rants about why "build in public" stopped meaning anything when everyone started doing it. We'll publish here every time we ship something material — which, given the cadence we're on, is roughly weekly.

The shape of the company we want to build is small, focused, and absurdly profitable. Not a hundred-person org with a content marketing team. A team that ships a product so good that the only reasonable response is to use it. The kind of company where the pricing page is two columns and a checkout button, the demo is a real product loaded with your data, and the founder writes the blog because there's nobody else to write it.

If any of this resonates, the easiest way to follow along is to book a demo and see the engine work on your repo, or subscribe to the newsletter. We'll be in your inbox roughly weekly. Never with a sales email.

— Vuk