Adzee

The problem

Producing a coherent ad set by hand — brief, headlines, body copy, and matching imagery — is slow and drifts off-brand, and a single naive prompt to a model produces generic, uncontrolled output that ignores a brand's identity. Adzee is a solo attempt to make that whole flow one brand-conditioned pipeline where every stage carries the same structured brand context and the output is checked before it is returned.

Constraints

• No independently measured usage, revenue, or accuracy data exists — this is a working build, not a launched product with a user base, and it is presented that way.
• Image generation is non-deterministic and can return weak results, so the pipeline cannot trust a single pass — quality has to be checked and corrected in-loop.
• Brand consistency has to hold across four distinct generation stages, not just one prompt, so brand context is threaded through every step rather than set once.
• Single builder across the entire surface — auth, data, pipeline, retrieval, and deploy — so scope choices had to stay narrow enough to actually finish and run.

Approach & key decisions

• Decompose generation into distinct, composable stages — creative brief, ten ranked headlines, per-image prompts, then short and long copy — each receiving structured brand context, rather than one monolithic prompt.

  Staging makes each step inspectable and independently tunable, and threading the same brand context (name, description, logo, primary color) through every stage is what keeps the output on-brand instead of generic.

• Add a self-correcting image-quality loop: generate, score against a configurable threshold, regenerate the weak ones before returning.

  Image models fail unpredictably; a closed loop with a quality gate is the difference between a demo that sometimes returns junk and a pipeline you can hand a result from.

• Stream the pipeline with async generators so the UI surfaces each stage as it completes.

  A multi-stage generation run is long; showing progressive results keeps the interaction responsive instead of blocking on the full run, and makes a failing stage visible rather than hidden in a spinner.

• Add Pinecone retrieval over past generations via OpenAI embeddings.

  Past outputs are the cheapest source of on-brand grounding; a retrieval layer lets the pipeline draw on prior generations rather than starting cold every time.

• Ship it as a real application — JWT auth, Prisma/Postgres model, Vercel Blob storage, and a Dockerfile — not a notebook or CLI toy.

  The product started life as a one-shot CLI ad creator and was deliberately grown into a deployable web app with persistence and auth, because the interesting problems (brand state, stored generations, multi-user) only appear once it is a real system.

What I built

• Built the staged GPT-4o pipeline: creative brief, ten ranked headlines, per-image prompts, and short/long copy, each stage fed the same structured brand context (name, description, logo, primary color).
• Implemented the image-quality loop — generate, score against a configurable threshold, and regenerate images that fall below it before returning the set.
• Wired streaming generation with async generators so each pipeline stage renders in the UI as it completes instead of blocking on the whole run.
• Modeled the domain in Prisma/Postgres — Users, Brands, per-brand Colors, and Generations — persisting prompts and generated image URLs.
• Integrated Pinecone with OpenAI text-embedding-3-small to embed and retrieve past generations.
• Wrote a from-scratch JWT auth layer with hashed, rotating refresh tokens (revocation and replacement chaining) and bcrypt password hashing.
• Persisted imagery through Vercel Blob and containerized the app with a Dockerfile and deploy scripts.

Outcomes

• A working, deployable end-to-end AI product — staged generation, a self-correcting image loop, auth, persistence, vector retrieval, and containerization — built solo.◧Self-reported · 24 commits; deployable build
• Brand-conditioned output across four stages rather than a single uncontrolled prompt, with structured brand context threaded through each step.◧Self-reported
• Image results are quality-gated and auto-regenerated below threshold rather than returned blind.◧Self-reported
• No usage, revenue, or accuracy metrics are claimed — none were measured. The demonstrated outcome is architectural completeness.◧Self-reported

Limitations & what's next

• No quantitative evaluation of creative quality — the image loop scores against a threshold, but there is no measured baseline for how much regeneration improves the final set. The next step is an honest offline eval of the scorer against human judgment.
• The refresh-token layer works but is not hardened: a token-TTL configuration bug means the auth lifecycle needs an audit and correction before I would call the security posture production-ready. I am not presenting token security as a selling point.
• No usage or accuracy data exists — it has not been run against real users or a labeled test set, so all claims here are architectural, not outcome-based.
• Retrieval over past generations is wired but its effect on output quality is unmeasured; I would want to test whether it actually improves on-brand grounding before leaning on it.
• It began as a one-shot CLI and grew into a web app; some seams from that evolution remain and would want consolidation before scaling to multiple concurrent users.