• 

  Details about the report process

• 

  Example of the Compass for Brands

• 

  Creator Compass Homepage

• 

  Explaining How it Works

CreatorCompass

Inspiration

CreatorCompass started with a problem I have seen from the agency side of creator sponsorships.

Most creator-marketing platforms begin by asking a brand to search through thousands of creators. That sounds useful, but it assumes the brand already knows what it is looking for. In reality, many brands do not begin with a particular YouTuber, creator size, campaign format, or even creator category in mind.

They begin with much more basic questions:

• Does creator sponsorship make sense for our product?
• What kinds of audiences should we be trying to reach?
• Should we work with educators, reviewers, entertainers, operators, or niche experts?
• Are we actually ready to pay for outreach?
• What would a credible first test look like?

Creator databases are good at helping someone search after those decisions have already been made. I wanted to build something that worked one step earlier.

CreatorCompass takes the one thing every brand already has, its own website, and turns it into a clear starting direction for creator marketing.

The guiding idea became:

Do not give a brand more names until it understands where it should go.

What CreatorCompass does

A user enters a public brand website. CreatorCompass reviews a bounded set of public pages and creates an evidence-backed report containing:

• A structured snapshot of the brand, product, audience, and use cases
• A sponsorship-readiness assessment
• The creator territories where the brand most naturally belongs
• Adjacent and experimental directions worth testing
• Tempting but strategically weak directions to avoid
• Campaign concepts, creator profiles, formats, and search phrases
• One recommended North Star route
• A five-step plan the brand can begin using immediately

CreatorCompass separates two questions that are often confused:

1. Is the brand ready for creator sponsorships?
2. Which creator audiences are the best fit?

A brand can have an excellent creator-audience fit while still lacking campaign tracking, a clear offer, creator access, onboarding documentation, or a useful demonstration. The product makes those gaps visible rather than hiding everything inside one vague score.

It also distinguishes website facts, model inference, assumptions, and unknown information. When a website cannot provide enough evidence, CreatorCompass can abstain, ask for clarification, or accept pasted brand context instead of inventing a confident answer.

How I built it

I built CreatorCompass as a TypeScript application with a React and Vite front end, a Hono API, and Cloudflare infrastructure.

The production system uses:

• Cloudflare Workers for the public application and API
• Cloudflare D1 for reports, jobs, usage tracking, and rate limits
• Cloudflare KV for report caching
• Cloudflare Queues for asynchronous analysis
• Cloudflare Workers AI for structured extraction and enrichment
• Mistral as a resilient secondary provider
• GPT-5.6 for bounded final strategic review
• Zod schemas across model, API, and storage boundaries

The analysis pipeline begins by safely reading a limited number of useful public pages. It extracts short evidence records rather than saving a full copy of the website.

From there, CreatorCompass builds a structured brand profile containing fields such as:

• Business model
• Product type
• Buyer and user roles
• Industries
• Use cases
• Jobs to be done
• Purchase motion
• Demonstrability
• Campaign asset type
• Important unknowns

Creator territory fit is then calculated in normal code. The model does not secretly invent the score.

The scoring system considers factors such as:

• Category and use-case match
• Buyer-role overlap
• Job-to-be-done overlap
• Content-format naturalness
• Purchase influence
• Evidence strength
• Explicit incompatibilities

GPT-5.6 receives a bounded candidate set rather than the entire creator economy. Its role is to reject weak routes, classify the defensible options, and choose a coherent North Star recommendation from structured evidence.

This bounded approach helped keep the product understandable, testable, and inexpensive enough to run as a public tool.

How I used Codex

Codex was involved throughout the build rather than being used for a single generated feature.

I used it to help:

• Design and scaffold the monorepo
• Build the website-ingestion pipeline
• Implement deterministic scoring
• Create model-provider adapters
• Define and validate structured schemas
• Build the report interface and compass visualization
• Add caching, queues, and database migrations
• Write unit, integration, and evaluation tests
• Diagnose production failures
• Improve accessibility and print behavior
• Deploy and verify the application on Cloudflare

Codex was especially valuable during iterative production debugging. I could provide a bad report, explain why the recommendation felt wrong, and then work through the code path that produced it.

My role was not simply to ask Codex to “build an influencer tool.” I made the central product and ethical decisions, including:

• Starting with one brand URL instead of requiring a brand and creator
• Working upstream of creator databases
• Separating readiness from territory fit
• Keeping deterministic scoring outside the model
• Requiring evidence-backed recommendations
• Allowing abstention when evidence is weak
• Preserving useful output when a model provider fails
• Avoiding automated mass outreach and contact scraping

Codex accelerated implementation, but the product direction came from repeatedly testing whether the result would actually help a real brand make a better decision.

Challenges I faced

The hardest problem was not creating a report. It was preventing a polished report from being confidently wrong.

An early version produced unrelated creator territories for an SEO software platform, including beauty, gardening, camping, and gaming. The report looked good, but the recommendations were weak.

The root causes were structural:

• Broad brand-readiness factors were inflating every territory score
• Loose substring matching created false relationships
• The taxonomy lacked enough B2B and technical creator territories
• Weak candidates were being added simply to fill category quotas
• Model-generated fields could influence scoring without enough semantic support

I rebuilt the fit logic so a territory must establish a real category, use-case, buyer-role, or job-to-be-done connection before it can rank. I also added specialist territories for areas such as SEO, developer tools, AI agents, open source, self-hosting, SaaS, agency operations, and growth marketing.

Another challenge was provider reliability.

Cloudflare, Mistral, and OpenAI could each fail in different ways, including timeouts, structured-output errors, grounding failures, billing exhaustion, and overly strict post-validation.

At first, any provider failure caused the public report to display a warning saying it needed another review pass. That made the product look broken even when its deterministic result was valid.

I changed the system so delivery quality is based on the report itself rather than which provider completed it. An unreadable website remains a real error. Insufficient evidence produces preliminary hypotheses. A grounded deterministic report is delivered normally and honestly records its analysis path.

I also had to solve smaller but very visible problems:

• Preventing raw identifiers from appearing in customer-facing copy
• Fixing malformed verb phrases in generated concepts
• Ensuring “rank tracking” was not mistaken for campaign attribution
• Making readiness dimensions appropriate for software as well as physical products
• Preventing duplicate queue execution
• Repairing report sharing when clipboard permission is denied
• Making the /100 score readable on mobile and in printed PDFs
• Removing blank pages from generated reports

These details mattered because CreatorCompass is intended to feel like a launchable product, not just a technical demonstration.

What I learned

I learned that reliable AI products need more than a good prompt.

The strongest parts of CreatorCompass came from deciding which responsibilities should belong to models and which should belong to ordinary code.

Models are useful for:

• Interpreting messy brand language
• Explaining audience connections
• Developing creative campaign directions
• Comparing a bounded set of strategic options

Code is better for:

• Eligibility rules
• Scoring
• Thresholds
• Evidence validation
• Rate limits
• Provider routing
• Caching
• Failure handling
• Preventing unsupported claims

I also learned that uncertainty can be a product feature.

An AI system does not become more useful by always producing a confident answer. Sometimes the most valuable result is:

The website does not tell us enough yet. Here are the exact questions that need answers before broad outreach.

That preserves user agency and makes the eventual recommendation more credible.

Finally, I learned how much product quality can improve when AI-assisted development becomes an ongoing dialogue. Codex helped me move quickly, but the best improvements came from looking at real output, noticing where it failed human judgment, and turning that judgment into code, tests, and stronger boundaries.

What is next

CreatorCompass is currently focused on determining strategic direction before creator selection.

The next stage would connect that direction to an agency workflow:

• Search for creators inside the recommended territories
• Evaluate channel fit and recent content
• Compare campaign portfolio structures
• Estimate practical sponsorship ranges
• Create campaign briefs
• Track outreach, deliverables, links, and outcomes

I deliberately kept those features out of the hackathon version. The first product needed to solve one problem clearly:

Given this brand, where should it go in the creator economy?

CreatorCompass now gives brands an evidence-backed answer, shows the reasoning they can inspect, and provides a route they can begin testing.

Built With

• ai
• cloudflare
• codex
• d1
• gpt-5.6
• hono
• kv
• mistral
• openai
• queues
• react
• typescript
• vite
• workers