As developers, we love automation but content creation is still painfully manual for most teams.
I kept seeing the same problem across founders, indie hackers, and agencies:
- Writing SEO blogs takes hours
- Landing pages are repetitive
- Social content is inconsistent
- Existing AI tools feel fragmented or overcomplicated
So I decided to build a tool to solve my own workflow problem first and that project became Minineo.
This post isn’t a promo.
It’s a breakdown of what I built, what worked, what didn’t, and what I learned along the way.
The Original Problem
My goal was simple:
Go from keyword → published content with as li...
As developers, we love automation but content creation is still painfully manual for most teams.
I kept seeing the same problem across founders, indie hackers, and agencies:
- Writing SEO blogs takes hours
- Landing pages are repetitive
- Social content is inconsistent
- Existing AI tools feel fragmented or overcomplicated
So I decided to build a tool to solve my own workflow problem first and that project became Minineo.
This post isn’t a promo.
It’s a breakdown of what I built, what worked, what didn’t, and what I learned along the way.
The Original Problem
My goal was simple:
Go from keyword → published content with as little manual work as possible.
But most tools:
- Generate raw text only
- Don’t respect SEO structure
- Break when you try to scale
- Leave publishing & formatting to you
I wanted something developer-friendly, predictable, and automatable.
The Approach I Took
Instead of one big AI prompt, I split the system into clear stages:
- Intent-first content planning
- Strict structure enforcement
- Usage limits handled server-side
- Publishing treated as a pipeline, not a button
That design decision saved me weeks later.
Architecture (High Level)
- Next.js for the app layer
- Supabase for auth, data, and RPCs
- Server Actions for usage enforcement
- AI models only handle generation not business logic
Key rule I followed:
- Never trust the client for usage limits
- Always enforce limits via server-side RPCs
This made the system production-safe early on.
Content Generation Strategy
Instead of “write a blog about X”, the AI gets:
- Fixed heading hierarchy
- Explicit SEO constraints
- Word count bounds
- Section responsibilities
This dramatically reduced:
- Hallucinations
- Fluff
- Rewrites
The output became predictable enough to automate publishing.
Media Was Harder Than Text
Text was easy. Media wasn’t.
Problems I hit:
- Hotlinking external images (bad idea)
- WordPress rejecting uploads
- Social platforms requiring different auth models
Solution:
- Download → upload → replace URLs at publish time
- Treat media as a post-processing step, not generation
- This separation kept the core clean.
What Didn’t Work
Being honest a few mistakes:
- Trying to support every social platform early
- Overengineering UI before workflows were stable
- Letting AI decide structure (never again)
Each rollback made the system simpler and more reliable.
What Worked Surprisingly Well
- Strict prompts > “creative freedom”
- Build-in-public feedback
- Treating content like data, not prose
- Shipping small, testable pieces
Why I’m Sharing This Here
Dev.to helped me countless times while building this.
If you’re:
- Building an AI SaaS
- Automating content workflows
- Enforcing usage limits properly
- Publishing to platforms programmatically
I hope something here saves you time or mistakes.
What’s Next
Next on my list:
- Smarter media enrichment
- Better scheduling reliability
- Even stricter content validation
Still learning. Still iterating.
If you’ve built something similar or hit the same challenges, I’d genuinely love to hear:
- What broke for you?
- What scaled unexpectedly?
- What would you do differently?
Happy to answer technical questions in the comments