CodexGenAI

Overview

CodexGenAI is an AI content studio I designed, built, and shipped solo in six weeks. It does three things: generates multi-slide carousels from a prompt or a rough outline, schedules the results across LinkedIn, Instagram, and X from a single visual queue, and scores post-publish engagement with sentiment analysis so creators can see which tone actually performs.

I owned every layer — the product decisions, the LLM prompting and output validation, the scheduling infrastructure, the Postgres schema and row-level security, the frontend, and the deploy. There was no designer and no second engineer.

The Challenge

Creators who post consistently lose hours a week to work that is mechanical rather than creative: reformatting the same idea into a carousel, resizing slides per platform, copying captions between three scheduling tools, and then having no reliable read on which posts landed.

The tools that existed each solved one third of that. Generation tools produced text but no scheduling. Schedulers assumed you arrived with finished assets. Analytics tools reported vanity metrics with no link back to the content decisions that produced them. Stitching all three together meant three subscriptions with per-seat pricing that does not make sense for a solo creator.

The engineering problem underneath was less obvious: an LLM is a badly behaved dependency. It returns prose when you asked for JSON, it produces a nine-slide carousel when the platform caps at ten but the design breaks at eight, and it is slow enough that a naive request-response UI feels broken. Any tool built on it has to treat malformed and slow output as the normal case, not the exception.

Solution

I built generation around a strict output contract rather than free-form prose. Every generation request specifies a schema — slide count, character budget per slide, tone — and the response is validated against it before the user ever sees it. A response that fails validation is retried with the validation error fed back into the prompt, and only a second failure surfaces as an error. In practice that turned a feature that intermittently produced unusable output into one that fails visibly and rarely.

The interface streams. Slides appear as they are generated rather than after a spinner, which changed the perceived speed of the feature more than any actual latency work did. Everything is keyboard-reachable — creators using this daily do not want to hunt for buttons.

Scheduling runs on a drag-and-drop queue backed by Postgres, with per-platform variants of a single post so a creator writes once and adjusts per channel rather than duplicating work. Sentiment scoring runs after publish and is joined back to the generation parameters, so the analytics view can answer "what tone worked" instead of just "what got likes".

Technical decisions worth explaining

Supabase over a hand-rolled backend was the decision that made a six-week solo build possible. Auth, Postgres, storage, and row-level security in one place meant I wrote authorization as database policy rather than as middleware I would have to audit on every new endpoint. For a single-developer product handling multiple users' content, having the tenancy boundary enforced by Postgres rather than by my own discipline was worth more than the flexibility I gave up.

I kept the LLM behind a thin internal interface from the first commit. Model quality and pricing in this category move monthly, and a provider swap should be a configuration change rather than a refactor. That boundary cost maybe half a day up front and has since paid for itself repeatedly.

Sentiment scoring runs as a scheduled job rather than on demand. Engagement data is not interesting until a post has been live for a while, so computing it lazily at read time would have meant paying inference cost on every dashboard load for numbers that had not changed. Batching it moved the cost from per-view to per-post.

• Schema-validated LLM output with error-feedback retry, instead of parsing model prose
• Streaming generation UI — slides render as they arrive
• Row-level security in Postgres as the tenancy boundary, not application middleware
• Provider-agnostic LLM interface behind a single internal module
• Batched post-publish sentiment scoring rather than per-request inference

Tech Stack

Outcomes

• Shipped to production in six weeks as a solo build, from empty repo to live URL — including auth, billing surface, generation, scheduling, and analytics.
• Cross-platform scheduling for LinkedIn, Instagram, and X from one queue, with per-channel variants of a single source post.
• Generation output moved from intermittently unusable to reliably schema-conformant once validation-with-retry replaced prose parsing.
• Inference cost per active user stayed flat as usage grew, because analytics scoring is batched per post rather than computed per dashboard view.

Need this kind of work?