Build a working tool for media buyers
A public build challenge asked applicants to create a working tool for a media-buying team.
Technical deep diveDeployed working prototype
Structured AI workflow · validation · stage-level fallbacks · human review
Aegis is an AI-assisted creative research pipeline for media buyers. It analyzes competitor pages, generates five campaign concepts, and runs a separate risk review.
I built the working prototype independently in five days for the It's Today Media build challenge. The application validates model output, checks product rules in code, protects secrets, shows pipeline state, and preserves earlier results when a later stage fails.
AI product developmentNext.jsGeminiFirecrawlZodRisk review
Engineering summary
Build the guardrails into 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
Address a real media-buying workflow
The brief asked for a working tool. I focused on repeated competitor research and campaign review.
Competitor research slows creative strategy
Teams need to review competitor positioning, offers, hooks, claims, audiences, and landing-page logic before they can plan a campaign.
Aegis creates structured, reviewable campaign direction
The prototype extracts page content, structures the findings, generates campaign concepts, and runs a separate risk review with lower-risk wording.
Working interface
See the product in context
The live prototype shows source input, structured analysis, generated concepts, and a separate risk-review stage.
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
Keep the product inspectable when services are unavailable
Aegis can run a fixed sample, use pasted text, or analyze a live URL.
Show the full workflow without external services
A fixed sample runs the complete pipeline immediately, even when external services are unavailable.
Bypass extraction for testing or recovery
A reviewer can paste page copy and still run Spyglass, concept generation, and Shield.
Run the live pipeline
A competitor URL runs through extraction, analysis, five-concept generation, and Shield review with a status for each stage.
Problem
Fast output can be ungrounded, malformed, or risky
The product must preserve source context, return predictable structure, and support human review.
Competitor pages contain useful evidence
Landing pages reveal audience assumptions, positioning, feature priorities, proof points, hooks, and conversion logic. Reviewing them consistently takes time.
Give concept generation a defined input and output
Unstructured output can sound polished and still be generic. Aegis grounds concepts in extracted page content and a required response shape.
Give risk review its own visible stage
Claims, promises, urgency, personal attributes, and other sensitive language require review before use.
Constraints
The five-day build needed clear contracts and limits
The prototype had to be conceived, built, documented, and deployed in five days.
The workflow needed several distinct stages, not a chatbot call inside 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
Validate each stage before starting the next
Each stage has one job, a defined output shape, and its own failure behavior.
Browser
Source input
The user enters a page URL or pastes source text. Pasted text also bypasses extraction when needed.
Server + external API
Extraction
Firecrawl retrieves page content from a URL. That text becomes the shared source for later stages.
Gemini task 1
Spyglass task
A Gemini task identifies the offer, audience, positioning, claims, hooks, calls to action, objections, and creative opportunities.
Typed contract
Schema validation
Zod validates the analysis before the application displays it. Invalid output is rejected.
Gemini task 2
Concept generation
A second Gemini task receives the structured findings and produces five campaign concepts. The application verifies the count.
Gemini task 3
Shield review
A third Gemini task checks the concepts against 12 risk categories and suggests lower-risk alternatives.
Application invariant
Correctness checks
The application validates Shield output and confirms that each flagged phrase appears in its concept.
Human review
Reviewable UI state
Valid results stay visible. Status messages explain what succeeded, what failed, and what still needs review.
Guardrails around the model
Do not trust model output by default
The system validates structure, checks product rules, protects credentials, shows provenance, and stops uncertain output from moving downstream.
Validate every model response before use
Zod schemas define the required output for each AI stage. The interface rejects data that does not match the schema.
Check product rules in application code
Aegis checks that generation returns five concepts and that each flagged phrase appears in its concept.
Show how each stage ran
Pipeline badges mark live, manual, skipped, and fallback states so reviewers know where each result came from.
Secrets stay on the server
Gemini and Firecrawl credentials are stored in server-side environment variables and are never exposed through NEXT_PUBLIC_ configuration.
Preserve useful results after a failure
Manual input, sample data, stage-specific errors, and preserved earlier results keep the run 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
Review the implementation 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
Apply product rules in the implementation
Make each stage easy to inspect
The interface separates source analysis, concepts, risk flags, and rewrites so reviewers can inspect each stage.
Use schemas as the contract between the model and the product
Zod schemas validate each AI stage. TypeScript types come from the same schemas, which reduces duplicate definitions.
Give each task one job and a clear dependency
Aegis separates analysis, concept generation, and risk review. Each stage receives the context it needs and returns an output the next stage can inspect.
Treat failure as a visible product state
Stage-specific fallbacks keep one provider or parsing error from erasing useful results. Status messages explain what remains available.
Failure tour
Preserve valid work when one stage fails
External services, parsing, quotas, and variable output can fail. Aegis shows those failures and preserves available results.
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.
MVP scope
Defer features that do not test the core workflow
The five-day prototype tested one workflow: competitor page in, reviewed campaign concepts out. Other features were deferred.
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
Check output before calling it useful
The prototype does not claim production benchmark results. These criteria guide manual review and 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
Improve source traceability in the next version
The current prototype uses supplied source material, but it does not link every finding or generated claim to a specific page passage.
The next version would link each claim to a source excerpt, URL, page section, and review status.
Lessons
How I build AI products
Define the task before calling the model
Each stage has a defined job, a typed output contract, and a visible review point.
Show reliability and failure in the interface
Provider errors, malformed JSON, and partial completion are expected conditions. The interface explains them.
Give reviewers the context needed to judge output
The interface shows source context, risk signals, alternatives, and clear places to accept, reject, or revise output.
Next iteration
Strengthen the reviewer workflow in the next version
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 the full workflow around the model: validated outputs, failure handling, visible state, secure configuration, stated limits, and a deployed interface.