When I first built Ozigi (initially WriterHelper), the goal was simple: give content professionals in my team a way to break down their articles in...
For further actions, you may consider blocking this person and/or reporting abuse
lol I just came from the previous post 🤣
All the feedback I gave - you have already incorporated it. It works really well. this is exactly what I wanted: giving it the necessary context so it can create posts in my preferred style.
edit: add demo video to the repo if you can, it will be really useful.
😁 This is great feedback for me honestly. I'm glad your suggestions were incorporated, even before you suggested them. 😅
I'm thinking of adding the video, and then a sort of documentation on what the app does exactly. It's actually a general use app and you don't have to be a dev/content professional or DevRel person to use it.
Anyone who posts insights on sm is the perfect user.
yeah, just make the ux super smooth because that's what a lot of people care about. I would say use #discuss tag in your posts if you want the feedback from the community here -- it targets entire devto community.
Thanksssss. I already made a lot of improvements. You can check it out.
oh, there's a v3 roadmap as well! Waiting for it!
Thank youuuuuuuuu.
Have you tried the V2?
not yet, I've high fever. I just go through the blog. Will try soon.
I did try the 1st version.
I'm so sorryyyyyyy.
Get well soon! <3
no need to sorry. virus should apologize.
Love the modular approach. I'm using Supabase on the other side of this — not for the content engine itself, but for the lead capture pipeline. My website chatbot (ChadBot) collects name, email, and interest through conversational intake, then writes directly to a Supabase pipeline_leads table via the REST API.
The Playwright integration is interesting — are you using it for content verification (checking how posts render on each platform) or for actual posting automation? That's the piece I haven't cracked yet. My agents generate platform-native content but the actual distribution is still manual because most platforms actively block automated posting.
Stack comparison: I'm on React + Express + Claude API with per-channel agent prompts that all reference a shared product dictionary. The dictionary approach has been key for keeping voice consistent across 8+ output formats.
Using Playwright for E2E tests.
Posting a quick update here for anyone who followed this: the next thing I tackled after v2 was the LLM selection question properly. A reader suggested Claude would give better content output than Gemini. Instead of just switching, I ran a structured benchmark across four constraints — JSON output stability, latency on the public sandbox, native multimodal ingestion, and tone quality. Wrote up the full ADR if you want the numbers.
Really like the modular angle here. I've been building something similar for my own apps where each "module" owns a part of the content lifecycle: research, drafting, repurposing, distribution. The piece I've found most fragile is state: making sure each stage actually has the context it needs instead of starting from scratch. Curious how you're persisting and passing state between modules.
In Ozigi, we solve this using what we call a 'Unified Context Schema.' Because we use Gemini 2.5 Flash with strict responseSchema enforcement, every module (Research, Drafting, etc.) is essentially a pure function. The 'Research' module is contractually obligated to output a specific JSON structure that the 'Repurposing' module expects. This eliminates the 'brittle parsing' issue you mentioned.
For persistence, we lean heavily on Supabase JSONB columns. Each campaign has a 'State' object in the DB. As a module completes its task, it performs an atomic update to that JSONB blob. This means if a user leaves and comes back, or if the distribution module needs to 'look back' at a raw research note from step one, the entire lifecycle is already hydrated in a single source of truth.
Essentially: Schema enforcement at the AI level + JSONB persistence at the DB level = Zero context loss.
This is so neat.
Looking forward to being able to publish directly to sm platforms 🚀
Thank you so much, Chris! I appreciate it.
This is the kind of changelog I trust because it is not just features, it is pain you removed. Pulling auth, calls, and UI out of one growing file into single responsibility components is one of those moves that feels boring until you have done it, then you cannot unsee the difference.
Centralizing types is also underrated. A strict core shape that the rest of the system has to obey is how you stop the quiet rot.
Curious about the localStorage dashboard state. How are you handling versioning and reset when the schema changes, so people do not get stuck in a weird state after an update