Ozigi v2 Changelog: Building a Modular Agentic Content Engine with Next.js, Supabase, and Playwright

When I first built Ozigi (initially WriterHelper), the goal was simple: give content professionals in my team a way to break down their articles into high-signal social media campaigns.

OziGi has now evolved to an open source SaaS product, oepn to the public to use and imnprove.

Here is the complete technical changelog of how I completely turned Ozigi from a monolithic v1 MVP into a production-ready v2 SaaS.

1. Modular Refactoring of The App.tsx (Separation of Concerns)

In v1, my entire application: auth, API calls, and UI—lived inside a long app/page.tsx file. The more changes I made, the harder it became to manage.

• Modular Component Library: I stripped down the monolith and broke the UI into pure, single-responsibility React components (Header, Hero, Distillery, etc.).

• Centralized Type Safety: I created a global lib/types.ts file with a strict CampaignDay interface (complete with index signatures) to finally eliminate the TypeScript "shadow type" build errors I was fighting.
• State Persistence: Implemented localStorage syncing so the app "remembers" if a user is in the dashboard or the landing page, preventing frustrating resets on browser refresh.

2. Using Supabase as the Database and Tightening the Backend

A major UX flaw in v1 was that refreshing the page wiped the user's progress.

• Relational Database & OAuth: I replaced anonymous access with secure GitHub OAuth via Supabase.
• Automated Context History: I engineered a system that auto-saves every generated campaign to a PostgreSQL database. Users can now restore past URLs, notes, and outputs with a single click.

• Identity Storage: Built a settings flow to permanently save a user's custom "Persona Voice" and Discord Webhook URLs directly to their profile.

3. Core Feature Additions

• Multi-Modal Ingestion: Upgraded the input engine to accept both a live URL and raw custom text simultaneously.

• Native Discord Deployment: Built a dedicated API route and UI webhook integration to push generated content directly to Discord servers with one click.

4. Update UI/UX & Professional Branding

• The Rebrand: Pivoted the app's messaging to focus entirely on content professionals, positioning it as an engine to generate social media content with ease and in your own voice.

• Open-First Onboarding: Designed a "Try Before You Buy" workflow. Unauthenticated users can test the AI generation seamlessly, but are gated from premium features (History, Personas, Discord) via an Upgrade Banner.

• Pixel-Perfect Layouts & SEO: Eliminated rogue whitespace and z-index issues using precise CSS Flexbox rules. Upgraded app/layout.tsx with professional OpenGraph and Twitter Card metadata.

5. Quality Assurance & DevOps (Automated Playwright E2E Tests)

• Automated E2E Testing: Completely rewrote the Playwright test suite (engine.spec.ts) to verify the new landing page copy, test the navigation flow, and confirm security rules apply correctly.

• Linux Dependency Fixes: Patched my CI/CD pipeline by ensuring underlying Linux browser dependencies (--with-deps) are installed so headless Chromium tests pass flawlessly.

What's Next? (v3 Roadmap)

With the Context Engine now stable, the foundation is set.
My plan for V3 is to fix the deployment pipeline:

• integrating the native X (Twitter)
• LinkedIn APIs so users can publish directly from the Ozigi dashboard.

What has been your biggest challenge scaling a Next.js MVP? Let me know in the comments!
Try out Ozigi
And let me know if you have any feature suggestions? Let me know!
Want to see my poorly written code? Find OziGi on Github.

Connect with me on LinkedIn!

Comments

[Anmol Baranwal]

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.

[Dumebi Okolo]

😁 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.

[Anmol Baranwal]

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.

[Dumebi Okolo]

Thanksssss. I already made a lot of improvements. You can check it out.

[Rohan Sharma]

oh, there's a v3 roadmap as well! Waiting for it!

[Dumebi Okolo]

Thank youuuuuuuuu.
Have you tried the V2?

[Rohan Sharma]

not yet, I've high fever. I just go through the blog. Will try soon.

I did try the 1st version.

[Dumebi Okolo]

I'm so sorryyyyyyy.
Get well soon! <3

[Rohan Sharma]

no need to sorry. virus should apologize.

[Chris Ebube Roland]

This is so neat.

Looking forward to being able to publish directly to sm platforms 🚀

[Dumebi Okolo]

Thank you so much, Chris! I appreciate it.

[CrisisCore-Systems]

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