Build something useful for media buying.
Aegis was built in response to a public challenge asking applicants to create a working tool that could deliver practical value to a media-buying team.
Technical deep diveDeployed working prototype
Structured AI workflow · validation · stage-level fallbacks · human review
Aegis is an AI-powered creative intelligence pipeline for media buyers. It turns competitor landing pages into structured strategy, five testable ad concepts, and risk-reviewed safer rewrites.
I built the working prototype independently in five days for the It's Today Media build challenge. The strongest part is not only the AI generation. It is the system around it: schema validation, application invariants, visible pipeline states, server-side secret handling, manual and sample recovery paths, and graceful stage-level fallbacks.
AI Product DevelopmentNext.jsGeminiFirecrawlZodRisk Review
Engineering summary
The guardrails are part of the product.
Aegis separates extraction, strategic analysis, concept generation, and risk review into distinct jobs with explicit contracts between them.
The application validates model output, rejects malformed data, verifies important product rules outside the prompt, protects server-side credentials, reports how each stage ran, and preserves valid earlier results when a later stage fails.
Origin
Built as a response to a real media-buying workflow.
The brief asked for a useful working tool. I chose a problem where competitor research, creative direction, and review pressure overlap.
Creative strategy carries repeated research drag.
Teams need to understand competitor positioning, offers, hooks, claims, audience assumptions, and landing-page logic quickly enough to turn the signal into useful direction.
Aegis turns source material into reviewable direction.
The prototype extracts source material, structures the strategy, generates campaign concepts, and adds a separate review layer for policy-risk signals and lower-risk wording.
Working interface
The product in context.
The live prototype exposes the full path from source input to strategic analysis, generated concepts, and a separate risk-review surface.
Competitive Pipeline
The main dashboard where a reviewer starts an analysis, selects a platform, and provides either a competitor URL or source text.
Spyglass Analysis
Structured analysis of the competitor offer, audience, hooks, claims, calls to action, emotional triggers, and creative opportunities.
Shield Review
A separate review stage that surfaces phrases that may deserve closer human attention and explains the associated risk signal.
Lower-Risk Suggestions
The final review state preserves the original concept while proposing lower-risk language for a human reviewer to accept, revise, or reject.
Three demo paths
The product stays inspectable under different conditions.
Aegis can prove the full experience instantly, bypass extraction for focused testing, or run the complete live pipeline.
Instant proof without external dependencies.
A hardcoded fixture shows the complete pipeline immediately. Reviewers can inspect the intended product experience even when external services are unavailable.
A practical testing and recovery path.
A reviewer can paste landing-page copy directly, bypassing extraction while still exercising Spyglass, ad generation, and Shield.
The complete production path.
A competitor URL runs through Firecrawl extraction, Gemini analysis, five-concept generation, and Shield review with stage-by-stage status reporting.
Problem
Fast output can still be ungrounded, malformed, or risky.
The difficult part is not producing more copy. It is preserving source context, predictable structure, and a visible path for human review.
Competitor pages contain useful signal.
Landing pages reveal audience assumptions, positioning, feature priorities, proof points, emotional hooks, and conversion logic, but reading them consistently takes time.
AI-generated ideas still need constraints.
Unstructured model output can sound polished while staying generic. Aegis keeps ideation connected to extracted source material and an explicit response shape.
Review needs a visible surface.
Claims, promises, urgency, personal attributes, and other sensitive language need deliberate review before confident copy reaches an audience.
Constraints
The useful version needed speed, contracts, and honest limits.
The prototype had to be conceived, built, documented, and deployed in five days.
The workflow needed to demonstrate more than a single chatbot call wrapped in a form.
Model output had to follow predictable contracts so the interface could validate and render it safely.
A failed external service or model stage could not erase every valid result from the run.
The system needed explicit boundaries around risk review, human judgment, and legal or platform approval.
API credentials and service calls needed to remain server-side.
Technical architecture
A staged pipeline with validation between model calls.
Each stage has a narrower job, a defined output shape, and its own failure behavior. That makes the system easier to inspect, debug, and extend.
Browser
Source input
The user provides a landing-page URL or pastes source text manually. Manual input also acts as a practical bypass when extraction is unavailable.
Server + external API
Extraction
Firecrawl retrieves usable page content when a URL is supplied. The extracted text becomes the shared source for the analysis stages.
Gemini task 1
Spyglass task
A focused Gemini task identifies offer, audience, positioning, claims, hooks, calls to action, objections, and creative opportunities.
Typed contract
Schema validation
Zod validates the analysis before the application accepts it. Invalid output is rejected instead of being treated as trustworthy UI data.
Gemini task 2
Concept generation
A second Gemini task receives the structured strategy and produces five campaign concepts. The application verifies the required ad count.
Gemini task 3
Shield review
A third Gemini task checks the concepts against a twelve-category risk checklist and suggests lower-risk alternatives for review.
Application invariant
Correctness checks
The application validates Shield output and confirms that a flagged phrase actually appears in the associated concept before displaying it.
Human review
Reviewable UI state
Valid results remain visible stage by stage. Status messages and fallback explanations tell the reviewer what succeeded, what failed, and what still requires judgment.
Guardrails around the model
Aegis does not treat AI output as trustworthy by default.
The system validates structure, checks product invariants, protects credentials, exposes provenance, and makes failure visible instead of quietly passing uncertain output downstream.
The model does not define truth by returning JSON.
Zod schemas are the source of truth for every AI stage. Responses are parsed and validated before the interface accepts them as usable data.
Important product rules are checked outside the prompt.
Aegis verifies that generation returns exactly five concepts and that phrases flagged by Shield actually appear in the associated ad.
Every stage explains how it ran.
Pipeline badges distinguish live, manual, skipped, and fallback states so reviewers can understand the origin and reliability of each result.
Secrets stay on the server.
Gemini and Firecrawl credentials are stored in server-side environment variables and are never exposed through NEXT_PUBLIC_ configuration.
External failure does not erase useful work.
Manual overrides, sample fixtures, stage-specific errors, and preserved earlier results keep the product inspectable when a provider fails.
Shield is risk triage, not a guarantee.
The interface presents Shield as a heuristic review layer that supports human judgment. It does not promise legal compliance or platform approval.
Technical snapshot
The implementation decisions behind the interface.
Next.js + TypeScript
Gemini
Firecrawl + manual-text bypass
Zod schemas at each AI stage
GitHub + Vercel
Server-side environment variables
Live, manual, skipped, or fallback
Sample fixture + manual-text override
What I built
Product thinking carried through the implementation.
Designed around inspection.
The interface separates source analysis, generated concepts, risk flags, and suggested rewrites so a reviewer can follow the reasoning path instead of receiving one opaque block of output.
Schemas define what the model owes the product.
Zod schemas make every AI stage easier to validate, display, debug, and extend. TypeScript types are derived from those schemas rather than maintained separately.
Small jobs, explicit dependencies.
Aegis uses separate tasks for strategic analysis, concept generation, and risk review. Each stage receives only the context it needs and produces an output the next stage can inspect.
Failure is treated as a product state.
Independent stage fallbacks prevent one provider or parsing failure from destroying an otherwise useful run. Specific status messages explain what remains available.
Failure tour
A partial failure should not become a total failure.
AI applications depend on external services, parsing, quotas, and nondeterministic output. Aegis treats those conditions as part of the product experience.
Extraction fails
The reviewer can provide source text manually instead of losing access to the rest of the workflow.
A model returns malformed output
The relevant Zod contract rejects the response and the application shows a specific fallback rather than rendering uncertain data.
Concept generation returns the wrong count
The application rejects the result because the five-concept invariant is part of the product contract.
Shield fails after earlier stages succeed
The valid analysis and campaign concepts remain available while the UI explains that the risk-review stage could not complete.
Intentional MVP scope
What I left out was part of the product decision.
The five-day prototype was scoped to prove competitor page in, safer ad ideas out. Features that did not strengthen that core loop were deferred deliberately.
Authentication
Not required to prove the core analysis, generation, and review workflow.
Billing
Monetization would have added implementation weight without improving the MVP’s central product signal.
Database and saved history
Persistent projects matter later, but they were not necessary to validate the end-to-end pipeline in the five-day build window.
Ad-platform integrations
Direct publishing would raise operational and policy complexity before the product had earned that level of automation.
Evaluation approach
What I check before calling an output useful.
This prototype does not yet claim production-grade benchmark results. These are the practical criteria I use to inspect its behavior and guide the next evaluation pass.
- Did each AI stage return schema-valid output?
- Did generation return exactly five campaign concepts?
- Were the concepts meaningfully distinct rather than cosmetic rewrites?
- Could strategic findings be traced back to the supplied source material?
- Did Shield identify risky language without flagging phrases absent from the concept?
- Did the fallback state preserve valid earlier-stage results?
Known limitation
Source traceability still needs a stronger interface.
The current prototype keeps each stage grounded in supplied source material, but it does not yet map every strategic finding or generated claim back to a precise page passage.
The next version would let a reviewer expand a claim to see the supporting excerpt, source URL, relevant page section, and review status before using the output downstream.
Lessons
What this project shows about how I build AI products.
AI gets better when the task has shape.
Aegis works because each stage has a defined job, a typed output contract, and a visible review point.
Reliability belongs in the experience.
Provider errors, malformed JSON, and partial completion are normal AI-product conditions. The interface should explain them instead of pretending they do not happen.
Human review needs product support.
A human-in-the-loop claim means more when the interface shows source context, risk signals, alternatives, and clear places to accept, reject, or revise the output.
Next iteration
From resilient prototype to stronger reviewer workflow.
The next version would add the features intentionally deferred from the MVP: saved projects, side-by-side competitor comparisons, source-linked evidence, reusable brand and risk rules, and explicit reviewer actions for accepting, rejecting, or revising generated concepts.
I would also formalize an evaluation set for grounding, creative distinctness, false-positive and false-negative Shield behavior, latency, and approximate cost per complete analysis.
I built more than an AI feature. I built the system around it: validated outputs, failure handling, transparent state, secure configuration, responsible limitations, and a complete path from idea to production deployment.