DEV Community: Pizza Cat

The End of Vibe Coding: Why I Switched to Structured AI Workflows

Pizza Cat — Thu, 11 Jun 2026 00:19:51 +0000

The End of Vibe Coding: Why I Switched to Structured AI Workflows

I spent 3 months "vibe coding" my SaaS. Then I realized I was spending more time fixing AI's mistakes than if I'd written it myself. Here's the system that changed everything.

In early June 2026, two HN threads with a combined ~1,300 comments told me something had shifted.

Thread 1 (~1,100 comments): "What was your 'oh shit' moment with GenAI?"
Thread 2 (~230 comments): "What tools have you made for yourself since AI?"

Both threads had the same pattern: people started with unfiltered excitement ("I built a whole app in one weekend!"), then hit a wall ("I'm spending more time fixing its bugs than writing code from scratch").

I know the feeling. I lived it.

The Vibe Coding Trap

When I started building MultiPost — an AI-powered cross-platform content tool — I was deep in "vibe coding" mode:

Me: "Make it look better"
AI: *adds Tailwind, restyles everything*
Me: "Add a filter by date"
AI: *adds a date picker, breaks the layout*
Me: "Fix that bug where posts don't show"
AI: *fixes the filter, introduces a null pointer*
Me: "Okay now add a dark mode toggle"
AI: *regenerates half the component from scratch*

Three weeks later I had a working feature and zero understanding
of how any of it actually held together.

This was my daily rhythm for weeks. Fast output, slow cleanup. The ratio kept getting worse as the codebase grew.

I was optimizing for speed of generation instead of speed of delivery.

The "Oh Shit" Moment

It came when I reviewed a feature I'd built entirely through unstructured AI sessions. The feature worked. But:

The code had 3 different patterns for the same thing (Auth0 token handling in one place, hardcoded keys in another)
Error handling was inconsistent — some functions returned null, others threw, others returned Result types
Database queries were scattered across the codebase instead of in a repository layer
A security reviewer would have cried

The AI didn't do this maliciously. It did this because I asked it to "fix this" and "add that" without ever giving it a structural framework. Every session was a fresh context with no memory of architectural decisions from the previous one.

The Fix: Structured AI Workflows

I switched from "vibe coding" to what I call structured AI workflows. The principle is simple:

Don't ask AI to write code. Ask it to execute a plan that you've designed together.

Here's the actual system I use:

1. Design Before Generate (15 minutes)

Before I let AI write a single line of code for a feature:

Step 1: Describe the feature in plain English back to AI
Step 2: Ask AI to list the components, data flow, and edge cases
Step 3: I review the plan — fix the architecture BEFORE code exists
Step 4: Only then: "Implement component X as designed"

The key change: I'm reviewing a plan, not debugging code. A plan review takes 2 minutes. Debugging generated code takes 30 minutes.

2. One Concern Per Session

This was my biggest mistake. I'd ask AI to "build the auth system" in one go — which means it generates auth UI, backend routes, database schema, and middleware all at once. Too much to review.

Instead:

Session 1: "Design the auth data model. Here are the constraints..."
Session 2: "Implement the auth API routes based on the data model from session 1"
Session 3: "Build the login page UI"

Each session has one clear output that I can fully review in under 5 minutes.

3. Enforce Structure with Prompt Templates

I stopped typing one-off prompts. Every session starts with a structured template:

CONTEXT: [what we're building, decisions made so far]
TASK: [single, specific output]
CONSTRAINTS: [tech stack, patterns to follow, things to avoid]
OUTPUT FORMAT: [expected delivery — code block, diagram, plain text]

This alone cut my "fix AI's mistakes" time by ~60%.

4. The "Review Gate" Practice

After every implementation session, before accepting the code:

Does it match the plan? (If not, reject — don't fix inline)
Are error paths handled? (If not, ask for them specifically)
Is it consistent with existing code? (Same patterns, same conventions)

This sounds like a lot. It takes 3-5 minutes per session and saves hours of later debugging.

The Before and After (Real Code)

Here's what a typical piece of vibe-coded auth logic looked like in my codebase — three different sessions, three different patterns:

- // Session 1: "Add auth check here"
- function getUserId(req) {
-   const token = req.headers.authorization?.split(' ')[1]
-   return token ? jwt.verify(token, process.env.SECRET).sub : null
- }
- 
- // Session 2: "Also add auth here"
- const requireAuth = (req, res, next) => {
-   try {
-     const user = jwt.verify(req.cookies.token, 'hardcoded-secret-123')
-     req.user = user
-     next()
-   } catch { res.sendStatus(401) }
- }
- 
- // Session 3: "Fix the auth bug"
- async function getUser(req) {
-   if (!req.headers['x-auth']) return { error: 'no auth' }
-   const result = await db.query(`SELECT * FROM users WHERE token = '${req.headers['x-auth']}'`)
-   return result.rows[0]
- }

Three approaches. Three error-handling styles. A hardcoded secret. A SQL injection waiting to happen. All doing "the same thing" because each session had no memory of the last.

After applying the structured workflow (one concern per session, review gate between each):

+ // repository/auth.js — single source of truth, one pattern
+ 
+ export function verifyToken(token) {
+   try {
+     return jwt.verify(token, process.env.AUTH_SECRET)
+   } catch {
+     return null
+   }
+ }
+ 
+ export function requireAuth(req, res, next) {
+   const token = req.cookies.token ?? req.headers.authorization?.split(' ')[1]
+   const payload = verifyToken(token)
+   if (!payload) return res.status(401).json({ error: 'unauthorized' })
+   req.userId = payload.sub
+   next()
+ }

One file. One pattern. One error-handling strategy. The AI wrote both versions — the difference was whether I gave it a structure to work within.

Real Numbers: Before vs After

For MultiPost specifically:

Metric	Vibe Coding	Structured Workflows
Time to feature completion	4-6 hours	3-4 hours
Code review reject rate	~40%	~10%
Post-deploy bugs per feature	3-5	0-1
Time spent debugging per week	8+ hours	2-3 hours

The interesting part: structured workflows are actually faster overall, even though they feel slower in the moment. The upfront planning time pays for itself in avoided debugging.

The Flow Difference

Here's what the two approaches look like side by side:

VIBE CODING:
  "Build feature X" → AI writes 500 lines → Deploy → Bug → Debug → Patch → Repeat
  │                      │                        │
  └── You skip design    └── 1 huge chunk         └── 30 min to find the issue

STRUCTURED WORKFLOW:
  "Design feature X" → Review plan → "Implement component 1" → Review → "Implement 2" → Review → Ship
  │                     │            │                          │
  └── 2 min plan        └── 2 min    └── small, reviewable      └── 3 min, catches bugs early

The vibe coding path feels faster because you see output immediately. The structured path is faster because you almost never backtrack.

The Bigger Pattern

Looking at that ~230-comment HN thread, multiple people independently came to the same conclusion:

"Most of the tools I write now are bridges to various SaaS products that have APIs but no CLIs."

"I made a harness to discipline AI output. The opposite of vibe coding. Using it daily."

"Superpowers guides the model to use careful, methodical approaches. Great for multi-step planning."

The community is self-organizing around the same insight: AI is a powerful junior engineer. Junior engineers need structure to produce quality work.

What I Use Now

I ended up building a CLI called Content Bridge to enforce this exact workflow. It's literally this article turned into a tool — you write a plan, review it, implement one component at a time, and the CLI enforces the structure so you don't have to remember the rules.

But you don't need any tool to start. You can begin today with one change:

Before your next AI session, spend 2 minutes writing down what you want it to produce. Not how — what. Review that plan before generating anything.

The generation is the easy part. The structure is the work.

What's your approach? Have you hit the same vibe coding trap? Drop your workflow (or horror story) in the comments — I read all of them.

The $11B Bet That Says Everything We Know About LLMs Might Be Wrong

Pizza Cat — Sun, 07 Jun 2026 03:47:21 +0000

The $11B Bet That Says Everything We Know About LLMs Might Be Wrong

Last week, a company that doesn't have a product, doesn't have a website, and is barely two months old raised $11 billion — the largest seed round in European history.

The company is called Ineffable Intelligence. The founder is David Silver — the man behind AlphaGo and AlphaZero at DeepMind. The valuation is $51 billion.

And here's the part that stopped me: they're not building another LLM.

The Bet

Every major AI company today — OpenAI, Anthropic, Google — is playing the same game:

Scrape as much human text as possible from the internet
Train a massive transformer to predict the next token
Use RLHF to make it sound helpful and harmless
Scale up and pray for emergent capabilities

Silver's thesis is that this entire paradigm is a dead end. Not a slowdown. A dead end.

His argument: language models learn from static human data. They're a compressed snapshot of what we already know. They can mimic reasoning, but they never actually interact with the world. They've never tried something, failed, adjusted, and tried again.

Real intelligence doesn't come from memorizing human text. It comes from acting in an environment and learning from the consequences.

If Silver is right, the entire "scale is all you need" school of thought is wrong. Bigger models, more data, more compute — eventually hits diminishing returns. The path to real AI isn't a bigger transformer. It's a fundamentally different architecture.

The $11B Question

The investors — Sequoia, Lightspeed, Google, NVIDIA, DST Global, the UK sovereign fund — are betting $11B that Silver is right.

But this is a moonshot, and everyone knows it. Silver's approach — training AI purely through reinforcement learning in continuous environments — has never been demonstrated at scale. AlphaGo and AlphaZero worked beautifully in the constrained world of board games. The real world is infinitely messier.

The skeptics say: "We've had RL for decades and it hasn't produced anything close to GPT-4. Why would this be different?"

The believers say: "Because nobody has tried it at this scale with this much compute."

Both are valid. That's why it's a $11B bet, not a $11M sure thing.

What This Means for Builders

This is the part I actually care about. Does this change anything for someone building products on top of AI today?

Yes, but not in the way you'd expect.

1. The LLM era is not the final form of AI

If you're building a business that depends entirely on API access to GPT or Claude, it's worth asking: what happens if the underlying paradigm shifts in 3-5 years?

This doesn't mean stop building. It means build abstractions. Your product shouldn't be coupled to one model provider. Your value prop shouldn't be "we use GPT-5." It should be "we solve X problem."

2. "Scale is all you need" is being questioned at the highest level

The fact that $11B flowed to an anti-LLM thesis tells you that even the biggest investors are not fully confident in the current path. They're placing a hedge — and that hedge is a $51B company.

If you've been feeling like the "just scale it" narrative was too simplistic, you're not alone. The industry is quietly admitting the same thing.

3. For indie developers: this doesn't change your game

Whether AI runs on transformers or reinforcement learning doesn't matter for the tools you're building today. What matters is: can you solve a real user problem?

The AI layer is becoming a commodity either way. The winners in the next wave won't be the ones with the best model — they'll be the ones with the best product and the best distribution.

The Bigger Picture

This isn't just about David Silver. It's a signal that the industry is entering what I'd call a post-scaling era.

For the last 5 years, the playbook was simple: take a transformer, make it bigger, feed it more data, get better results. That playbook is showing cracks. GPT-5 hasn't shipped. The gap between GPT-4 and GPT-4.5 was noticeably smaller than GPT-3 to GPT-4. Diminishing returns are real.

The industry is splitting into three paths:

Path	Who	Thesis
A — Keep scaling	OpenAI, Anthropic, Google	More compute, more data, more modalities
B — Start over	Silver, Ineffable Intelligence	RL from first principles, different architecture
C — Build on top	Everyone else	Model layer is a commodity; product and distribution win

As product builders, Path C is where we live. And that's fine — because the most valuable companies of the last 10 years weren't the ones that built the infrastructure. They were the ones that built on top of it.

What do you think — is Silver's bet visionary or delusional? I go back and forth every time I think about it. Drop a comment, I read all of them.

---

I'm a solo developer building MultiPost — a content repurposing tool for indie hackers who write on multiple platforms. I write about AI trends, SaaS development, and what it's actually like trying to get to $500 MRR as a solo founder.

Why a Chinese indie hacker built yet another content repurposing tool

Pizza Cat — Sat, 06 Jun 2026 09:07:01 +0000

Why a Chinese indie hacker built yet another content repurposing tool

I'm a full-stack developer from China. I make SaaS tools for the global market.

I have 4 hours a day. That's it. Full-time job takes the rest.

This is the story of why I built MultiPost — a content repurposing tool that currently has $0 MRR and zero paying users. And why I'm sharing everything.

The pain that started it

I write on Dev.to, Twitter, and soon LinkedIn.

Each platform has its own culture:

Dev.to wants technical depth
Twitter needs short punchy threads
LinkedIn prefers professional storytelling

If you write one post and copy-paste it everywhere, it fails on every platform. If you rewrite for each platform, you spend 3x the time.

I don't have 3x the time. I have one hour for content.

So I did what developers do: I looked for a tool.

What I found (and why I didn't buy)

Here's what the market looks like:

Tool	What it does	Problem
Cue	Schedule across platforms	No AI rewriting
SocialEcho	AI content repurposing	Too expensive for my scale
Buffer	Social media management	The new AI features are promising but locked behind high tiers
RepostEngine	YouTube → 10 platforms	Single-direction (video-only)

None of them did exactly what I needed:

Take one piece of content
Rewrite it for each platform's format
Let me edit before posting
At a price that makes sense for a solo dev

So I built it.

MultiPost: what it does

A content repurposing tool that rewrites your posts for different platforms — not translates, rewrites.

Input: one blog post / tweet / thread
Output: platform-optimized versions for Dev.to, Twitter, LinkedIn, and more
AI-powered but human-editable

The MVP took me 3 weeks. I work on it in the evenings after my day job.

The honest numbers

Here's where we stand today:

Users:        0 (well, 2 — me and a friend)
MRR:          $0
Status:       Live at multipost.ccwu.cc

$0 MRR. I'm sharing this because the indie hacker community taught me that transparency builds trust, and trust is the only asset you have when you start from zero.

Marc Lou (ShipFast) once posted a Stripe screenshot showing $0 MRR weeks after launch. That gave me more courage than any "how I made $100K in 30 days" post ever did.

What I'm going to share here

From today, I'll document this journey publicly:

Build logs — features I built, bugs I fixed, users I (tried to) get
Numbers — good or bad
Mistakes — I'll make plenty
Lessons — what works and what doesn't for a Chinese dev trying to go global

If you're an indie hacker, a solo dev, or someone who thinks "I can't start because I don't have enough time" — I want to show you what's possible with 4 hours a day.

Why I'm writing this in English

Someone asked me: "Why not write in Chinese? The audience is huge."

Two reasons:

I want to earn USD — building for the global market means being where the customers are
Chinese devs need representation — there are thousands of developers in China building amazing things, but almost nobody tells their story in English

I'm not a native English speaker. Some sentences will sound weird. That's okay. Building in public isn't about perfect grammar — it's about being real.

What's next

In the next post, I'll share the week 1 data: how I'm approaching cold start, who I'm reaching out to, and what the first user feedback looks like (if I get any).

If you're building something similar, or you've gone through the $0 → $1 journey — I'd love to hear your story in the comments.

Building @MultiPost — content repurposing for the solo creator. Follow for build logs, honest numbers, and lessons from a Chinese indie hacker.

Every AI Content Sounds the Same Now. Here's Why That's a $100B Problem.

Pizza Cat — Thu, 04 Jun 2026 00:01:24 +0000

Building MultiPost — an AI content distribution tool with a built-in humanization layer. Find me on Indie Hackers as pizzacat.

Building an AI-Powered SaaS with Nuxt 3 + Supabase: Full Architecture Breakdown

Pizza Cat — Mon, 01 Jun 2026 03:14:50 +0000

Last week I built an AI-powered content repurposing tool called MultiPost. You write one article, it generates platform-optimized versions for Twitter, LinkedIn, Dev.to, Reddit, and Indie Hackers.

The product works. The AI engine cost ~¥0.01 per conversion. The whole thing went from zero to deployed in ~48 hours.

But this post isn't about the product. It's about how it works under the hood — the architecture decisions, the AI prompt design, and the deployment tricks I learned along the way.

The Architecture at a Glance

Here's the full stack:

Frontend (Nuxt 3 SSR)
  ├── / → Landing Page
  ├── /convert → AI Conversion UI
  ├── /dashboard → Conversion History
  └── /settings → Account + Dev.to Integration

Server (Nuxt + H3)
  ├── /api/convert → DeepSeek AI Conversion
  ├── /api/history → Supabase CRUD
  ├── /api/devto → Dev.to Publish Proxy
  └── /api/auth → Supabase Auth Helpers

Database (Supabase)
  ├── profiles → User profiles
  ├── conversions → AI conversion history
  └── usage → Usage tracking

Deployment (Netlify)
  └── CNAME → multipost.clb520.ccwu.cc

Key decision: I used Nuxt 3 server routes (H3) for all API endpoints — no separate backend. This means frontend and API are deployed as a single artifact. For a solo dev building a Micro-SaaS, this is a massive productivity win.

The AI Engine: Prompt Design That Actually Works

The heart of the app is the conversion engine. Here's the flow:

Input Article (markdown text)
  → DeepSeek Chat API (single prompt, no chain)
  → JSON Response with 5 platform variants
  → Parse → Validate → Display in Tabs
  → User Edits → Copy or Publish

Why DeepSeek (not Claude or GPT-4)

Three reasons:

Cost: ¥0.001 ≈ $0.00014 per 1K tokens. A full conversion costs ~¥0.01.
Chinese developer friendly: API registration and billing work with Chinese payment methods. No Stripe requirement.
Quality: For content rewriting (not creative generation), DeepSeek matches GPT-4 at 1/30th the cost.

At $0.0014 per conversion, even at 1000 conversions/month, the AI cost is $1.40. This makes the $19/month pricing viable with 90%+ margins.

The Prompt Architecture

Single-prompt design, not chain-of-thought:

{
  "system": "You are a content repurposing expert...",
  "messages": [
    {
      "role": "user",
      "content": "Convert this article for 5 platforms.\n\nArticle:\n{input}\n\nReturn JSON: { twitter: { tweets: [string] }, linkedin: { text: string }, devto: { markdown: string }, reddit: { text: string }, indiehackers: { text: string } }"
    }
  ],
  "response_format": { "type": "json_object" }
}

Key lessons learned:

JSON mode is non-negotiable. Without response_format: json_object, the model occasionally adds explanatory text that breaks parsing.
Platform-specific context matters more than word count limits. Telling the model "Twitter wants a hook in every tweet" produces better results than "write 7 tweets under 280 chars."
Example-driven prompts beat instruction-only prompts. The v1 prompt was pure instructions. v2 included one example conversion. Output quality jumped significantly.
Temperature = 0.7 for creative rewrites, 0.3 for technical content. Technical articles stay closer to the source. Marketing content gets more variation.

Robust Parsing

DeepSeek's JSON mode is good but not perfect. Occasionally you get:

Escape character issues in code blocks
Truncated responses (token limit hit)
Missing keys in the JSON

The fix: a safeParse() function that validates each platform variant and falls back to the raw input for any that fail:

function safeParse(json: string): ConversionResult {
  try {
    const parsed = JSON.parse(json)
    const platforms = ['twitter', 'linkedin', 'devto', 'reddit', 'indiehackers']
    const result = {}
    for (const platform of platforms) {
      result[platform] = parsed[platform] ?? { text: rawInput }
    }
    return result
  } catch {
    return fallbackToRaw(input)
  }
}

Supabase: Database + Auth in One

Supabase does double duty — authentication and data storage. Here's the schema:

Tables

-- Profiles (auto-created on signup)
create table profiles (
  id uuid references auth.users primary key,
  email text,
  full_name text,
  created_at timestamp default now()
);

-- Conversion history
create table conversions (
  id uuid default gen_random_uuid() primary key,
  user_id uuid references profiles(id),
  input_title text,
  input_content text,
  output jsonb,  -- stores all 5 platform versions
  created_at timestamp default now()
);

-- Usage tracking
create table usage (
  user_id uuid references profiles(id) primary key,
  conversion_count int default 0,
  period_start timestamp default now()
);

-- RPC for atomic increment
create or replace function increment_usage(user_id uuid)
returns int as $$
  update usage
  set conversion_count = conversion_count + 1
  where id = user_id
  returning conversion_count;
$$ language sql;

RLS Gotcha

The biggest Supabase issue I hit: RLS without explicit GRANTs causes silent 500 errors.

For anon role (pre-auth), you need:

GRANT USAGE ON SCHEMA public TO anon;
GRANT ALL ON ALL TABLES IN SCHEMA public TO authenticated;

Without this, Supabase returns a generic 500 error that tells you nothing useful. I spent an hour debugging this.

Deployment: The Cloudflare Lesson

Originally I targeted Cloudflare Pages. Then my Pages got blocked due to an API token leak (rotated immediately, but Cloudflare's abuse detection flagged it).

The workaround: Netlify.

Deployment flow:

npm run build
npx netlify deploy --prod --dir=.output/public

Netlify handles Nuxt 3 SSR out of the box. Server routes work without any adapter configuration.

Then I pointed multipost.clb520.ccwu.cc at Netlify via a CNAME record. The trick with SSL was: turn off Cloudflare proxy → let Netlify auto-provision Let's Encrypt → turn proxy back on.

What I'd Do Differently

Start with a landing page, not the full product. I did this ✓. The landing page validated the idea before I wrote a line of product code.
Token rotation before GitHub push. This is how I lost Cloudflare Pages. Rotate all tokens before the first commit, not after.
Supabase RLS from day one. Add GRANT permissions to your migration script immediately. Don't wait for the 500 error.
Monorepo > separate repos. Frontend, API, and database all in one Nuxt 3 project means one deploy command. For a solo dev, this is faster.
Price higher. I started at $19/month. After seeing what people actually pay for tools like Content Snare ($29) and Senja ($39), $19 feels low.

The Numbers

Metric	Value
Time to first deploy	~48 hours
AI model	DeepSeek Chat
AI cost per conversion	¥0.01 (~$0.0014)
Infrastructure cost/month	$0 (Netlify free + Supabase free)
Code size	~800 lines Vue, ~200 lines API
Database	Supabase (3 tables, 1 RPC)

If you're building a Nuxt 3 SaaS and have questions about the architecture, AI integration, or deployment — drop a comment. I'll share whatever I can.

And if you want to try MultiPost for your own content distribution: multipost.clb520.ccwu.cc — free tier available, no credit card needed.

Built with Nuxt 3, Supabase, DeepSeek. Deployed on Netlify. Written by a solo dev who hates copy-pasting.

MultiPost Dev.to Integration is Live! 🎉

Pizza Cat — Sun, 31 May 2026 11:09:30 +0000

Good news! MultiPost now supports one-click publishing to Dev.to!

What is MultiPost?

MultiPost is an AI-powered content repurposing tool. You write once, and it generates platform-optimized versions for Twitter, LinkedIn, Dev.to, Reddit, and Indie Hackers.

What just happened?

This article was published directly from the MultiPost converter using the new Dev.to API integration. No copy-paste, no manual reformatting.

Tech stack: Nuxt 3 + Supabase + DeepSeek AI + Netlify

If you are a solo developer creating content, this tool saves hours of manual distribution work.

Check it out: https://multipost-saas.netlify.app

I Was Spending 10 Hours a Week Copy-Pasting Content. Here's What I Learned Building the Fix.

Pizza Cat — Sat, 30 May 2026 06:28:22 +0000

I Was Spending 10 Hours a Week Copy-Pasting Content. Here's What I Learned Building the Fix.

Thursday night, 11:47 PM.

I had just finished writing a tutorial about Vue 3 + Cloudflare Workers. Good content. Solid code examples. The kind of thing that should get me eyes.

Then I spent the next 52 minutes doing this:

Copy the article to Dev.to — need to add frontmatter, fix the code block formatting, rewrite the intro to be shorter
Copy a thread version to Twitter — 280 char limit, break into 7 tweets, make each one a hook
Copy to LinkedIn — professional tone, line breaks every 2-3 sentences, no code blocks
Copy to Reddit — conversational, shorter, don't sound like a salesman
Copy to Indie Hackers — narrative style, add the "I'm a solo dev" angle

Same content. Five different formats. Zero value added.

I did the math: over the last 3 months, that's 130 hours. Hours I could have spent building product, talking to users, or — you know — sleeping.

And the worst part? I wasn't even doing it well. The LinkedIn version looked like a Dev.to article. The Reddit post got removed by AutoMod for "promotion." The Twitter thread had a typo in tweet #3 that I didn't catch until 2 days later.

This is the part nobody tells you about being a solo creator:

Writing the content is 30% of the work. Distributing it is the other 70%.

And most of us pretend that 70% doesn't exist. We post to one platform, maybe two, and tell ourselves "the algorithm is broken" when nobody reads it.

But here's the thing I realized: the problem isn't that we're lazy. The problem is that the tools don't exist.

There's no "write once, publish everywhere" for indie developers. Not really. The enterprise tools are $500/month and designed for marketing teams. The free tools are half-baked and don't understand code.

So I decided to build it.

What I Built

MultiPost — write once, AI repurposes for every platform.

You write a blog post, a tutorial, or even just a thought. MultiPost generates platform-optimized versions — Twitter thread, LinkedIn post, Dev.to article, Reddit post, Indie Hackers story — in the time it takes you to make coffee.

The AI doesn't just reformat. It understands that:

Twitter needs a hook every 280 characters and a thread structure
LinkedIn needs professional tone, paragraph spacing, storytelling
Dev.to needs proper frontmatter, code blocks, a technical audience voice
Reddit needs to sound like a human, not a marketer
Indie Hackers needs narrative, numbers, the "solo founder" angle

One article. Five versions. Three minutes.

Here's What I Learned Building Day 1

1. Start with distribution, not product

I built the landing page before the actual tool.

A lot of developers will hate this advice. "Ship first!" "MVP!" "Move fast!"

But here's the truth: I built a 6-component landing page with an email signup form in ~2 hours. If nobody signs up, I just saved myself weeks of building something nobody wants.

The rule I set: 100 email signups or I pivot.

No marketing team. No ads. Just a landing page and organic content.

2. The pricing tells the story

Free → $19/month → $49/month.

$19 is "I'm a serious creator." $49 is "I'm making money from content."

I didn't invent these numbers. I looked at what Indie Hackers and creators actually pay for tools like this. Content Snare? $29/month. Senja? $39/month. Castmagic? $49/month.

The solo creator market has a very clear price ceiling: $49/month. Above that, you're selling to agencies, not individuals.

3. AI changes the build equation

This landing page + API endpoint took ~2 hours. With AI assistance.

Two years ago, that would have been a full day — writing CSS, debugging the form, setting up the database, configuring the deployment.

The AI didn't write everything. But it wrote enough that I could focus on the decisions that actually matter:

What problem am I solving?
Who is this for?
Is the messaging clear?

Code is cheap in 2026. Clarity is expensive.

The Tech Stack (Brief Version)

Frontend: Nuxt 3 + TailwindCSS → Cloudflare Pages
Backend: Nuxt Server API → Cloudflare Workers  
Database: Supabase
AI: Claude API (coming when I build the engine)
Payments: Stripe (eventually)

Why Nuxt 3? Because I can write frontend and API routes in the same project, and deploy both to Cloudflare Pages with a single build command.

What's Next

I'm building this entirely in public.

If this resonates:

Drop your email at the landing page — early access gets 50% lifetime
Follow me on Twitter/X — I post daily build updates
Reply with your workflow — what platform gives you the best ROI? What's the most painful part of distribution?

I ship the AI engine next week.

P.S. The irony of repurposing this article across 5 platforms using a tool that doesn't exist yet is not lost on me. I'll let you know how long the manual version takes.