Canary — Seeing What Your Market Isn't Showing You

Overview

Global news coverage varies dramatically by geography. The same trade deal gets framed as a win in one country and a conditional partnership in another. A story dominating headlines in one market might not appear at all in another. These gaps aren't editorial quirks — they represent real information asymmetry that shapes how people understand the world.

No existing tool is designed to surface these gaps. Aggregators flatten coverage into consensus. AI search tools synthesize information into a single answer, destroying the signal that lives in the disagreement between sources.

The goal: Build a monitoring tool that ingests news from multiple international markets, detects where coverage meaningfully diverges, and surfaces those gaps in a format people can act on.

Canary is a solo 0→1 product. I defined the problem, shaped the strategy, designed the experience, architected the system, and shipped a working MVP — then iterated the core model based on what I learned.

Role

Sole designer, product owner, and builder

This was a solo project across every discipline. There was no team to delegate to — every decision, from strategic framing to pixel-level detail, was mine to make and mine to ship.

• Defined the product vision, audience, and strategic positioning from scratch
• Developed a Jobs-to-Be-Done framework with three tiered jobs that defined MVP scope and sequenced the roadmap
• Created a complete experience architecture: object model, primary task flow, failure modes, and empty states — all before writing a line of code
• Designed and shipped the full UI across multiple interaction models as the product evolved
• Established design principles that became standing constraints for every build decision
• Built the AI-powered ingestion pipeline: multi-market news capture, cross-market matching, and divergence detection
• Optimized pipeline economics — reduced per-run cost by over 90% through model selection and prompt architecture decisions
• Managed a 17+ epic build plan with numbered ticket specs, a handoff protocol, decision authority framework, and preservation-first change control

Approach

Starting with the strategic crux

Before designing anything, I needed to answer a make-or-break question: Would knowing that a story is big news in one market and invisible in another actually change how someone sees the world? If the answer was no, nothing downstream mattered. I framed this as a demand-side crux — the technical challenges were real but subordinate to whether the core signal was valuable.

To test this, I defined three types of divergence signal, each creating a different kind of value:

Uncovered — a story prominent in one market with no coverage in another. The strongest signal.

Misaligned — same story, different framing and implied outlook across markets.

Coverage gaps — same story, but different facts reported or omitted.

The MVP bet: start with the strongest, cleanest signal (uncovered stories) and validate whether users found it meaningful before layering in subtler signal types.

Jobs-to-Be-Done as the scope knife

I structured the product around three sequential jobs, each building on the previous:

1. Market Visibility — access an information ecosystem you're currently locked out of
2. Divergence Recognition — identify where coverage meaningfully differs between markets
3. Context for Reasoning — get enough supporting evidence to form your own view

Job 1 is valuable standalone. Job 2 requires Job 1. Job 3 requires Job 2. This hierarchy became the scope knife — if a feature didn't serve one of these three jobs in sequence, it wasn't in the MVP.

Experience architecture before code

I built the complete UX foundation before writing any code:

Object model — The core entities weren't designed in a vacuum and handed to engineering. They were shaped by UX intent and build constraints at the same time — what the user needs to see, what the database can efficiently store and query, and what the AI pipeline can reliably produce at a cost that doesn't kill the project. Every entity in the model had to survive three questions: Does the user understand this without a footnote? Can I structure data around it? Can I afford to generate it per run?

The naming principle was strict: if a noun needs a footnote to make sense to the user, it's the wrong noun. But naming was only half the work. The shape of each entity — what it contains, how it relates to others — was equally driven by what was technically and economically viable. System internals (divergence scores, cluster IDs, pipeline run metadata) exist but never surface in the interface.

One view, one flow — The user opens Canary, sees the day's most significant cross-market signals, scans for what matters, drills into detail with side-by-side market comparison, and clicks through to primary sources. No search, no configuration, no saved preferences. Browse and drill-down, not query and configure.

Failure modes as trust design — Every failure state follows one principle: tell the user what the system knows and what it doesn't. Partial data gets disclosed, not hidden. Stale data stays visible but marked. Missing sources get explicit notices. A user will forgive incomplete data. They won't forgive being misled by it.

The first model: article-first comparison

The MVP shipped with an article-first interaction model. The primary surface was a ranked list of coverage gap cards — each representing a specific article or story where cross-market divergence was detected. Users scanned by headline, sector, and signal type, then drilled into a detail view with side-by-side market comparison.

The two-panel comparison was the core design moment. One side populated with coverage, the other showing a dashed border and explicit "No coverage detected" message. Absence rendered as clearly as presence — making the product's value tangible at the point of interaction.

This model validated the core bet. The signal was real — people could immediately see the gaps. But it also surfaced a structural limitation.

What the article-first model taught me

Article-level comparison worked for the strongest signal type (uncovered stories), but it broke down for subtler divergence. When both markets covered the same event but framed it differently, showing two articles side by side didn't make the framing difference legible. The user had to read both articles and do the comparison work themselves — which is exactly what Canary was supposed to eliminate.

The article-first model also made the product feel reactive rather than curated. A ranked list of individual coverage gaps, refreshed twice daily, read like a feed. Users had no anchor for why a particular gap mattered or how it connected to a broader situation they were tracking.

The insight: the right unit of analysis wasn't the article or even the story. It was the topic — a bounded current situation that multiple markets are covering in materially different ways.

The pivot: topic-first comparison

I restructured the entire interaction model around curated topics:

Topics as the primary entity. A topic is a higher-level abstraction above stories — "AI export controls" is a topic; "TSMC halts chip exports" is a story within that topic. Each pipeline run extracts 3–5 focus topics from the day's coverage, ranked by cross-market divergence significance.

POV-first comparison model. Topics are extracted from a default point-of-view market (currently US). For each topic, the system finds matching coverage in other tracked markets and analyzes how framing, emphasis, and prominence differ. This isn't a synthetic aggregate — it's actual stories from other markets matched to the same topic.

A richer divergence model. The original three signal types evolved into five reason labels, each telling the user why the divergence matters:

1. Conflicting claims — material factual disagreement between markets
2. Not covered — topic absent in other markets (with a confidence gate to avoid false negatives)
3. Framed differently — same topic, different angles
4. Buried — both cover it but prominence differs significantly
5. Earlier elsewhere — other markets covered this before the POV market

Each topic card shows one primary reason label. Drilldown shows all applicable labels.

Claim Callout as a high-signal flag. The most important new design element is the Claim Callout — a rare flag that fires only when markets make materially incompatible factual claims about the same situation. It has a strict five-condition trigger test to prevent false positives, and it surfaces separately from the main divergence score. This is the sharpest signal in the product — the moment where cross-market disagreement becomes genuinely consequential.

Design decisions shaped by the product's evolution

Surface language, not system language. This principle held through the pivot. The interface uses the vocabulary the user already speaks: topics, coverage gaps, sources — not divergence scores, salience composites, or capture run IDs. Learnability over internal precision.

Absence as signal. The two-panel comparison survived the pivot because it's the design moment where Canary's value becomes tangible. An empty panel with "No coverage detected" communicates more than any summary could. This principle extended to the topic cards: per-market coverage indicators (e.g., US 5/6, CN 3/4, DE 0/3) show at a glance where the gaps are.

Preservation-first change control. The pivot could have been destructive — throw out the article-first model and rebuild. Instead, I established a preservation-first build policy: existing functionality stays unchanged unless a task explicitly targets it. Prior phases are valid artifacts, not disposable exploration. This let me pressure-test the topic-first model without burning the working product underneath it.

One intentional default. Archived phases must not silently reappear as the default experience. This rule prevented the kind of regression where a user launches the app and sees a zombie version of the old model because someone forgot to update a route.

Outcomes

• Shipped a working MVP from zero — strategy through deployment — as a solo builder, then iterated the core interaction model based on what I learned
• Defined and validated a JTBD framework that cleanly sequenced the entire roadmap across both the article-first and topic-first models
• Created an experience architecture (object model, task flow, failure modes) that served as the single source of truth for every build decision — and survived a major model pivot
• Evolved the divergence model from 3 signal types to 5 reason labels plus a Claim Callout system with a strict trigger test, based on what the article-first model taught me about signal clarity
• Created a visual design language — signal type badges, market coverage indicators, two-panel comparison layouts, and the Claim Callout treatment — that made the product's abstract analytical concepts immediately legible without explanation
• Built an AI pipeline that captures and analyzes international news coverage across multiple markets on a daily cadence
• Reduced pipeline operating cost by over 90% through model selection and prompt architecture optimization
• Established a build methodology (epic structure, ticket specs, handoff protocol, decision authority levels, preservation-first change control) that managed complexity across 17+ epics without a team

What this reveals about how I work

Canary is a story about building, learning, and evolving. The article-first MVP validated the central question — cross-market divergence is a real, visible signal. But the MVP also revealed its own limitations: article-level comparison didn't make subtle framing differences legible, and a feed of individual gaps lacked the narrative structure users needed.

The pivot to topic-first comparison wasn't a failure of the first model — it was the natural consequence of using the first model seriously enough to see where it broke down. I started with a foundational question, built the simplest version that could test it, learned from what worked and what didn't, and restructured the product around a better unit of analysis.

The preservation-first build policy is how I manage that kind of evolution without losing what I've already built. Prior phases are reference states, not trash. The build methodology — decision authority levels, change framing, explicit preservation rules — exists because a solo builder needs more discipline than a team, not less.

What I'd do differently

• Would have validated the demand-side assumption with real users earlier, before investing in pipeline infrastructure. The strategic framing was sound but the conviction came from reasoning, not from putting a prototype in front of people.
• The article-first model ran longer than it needed to. I could have recognized the topic-level insight sooner if I'd been more systematic about cataloging the cases where article comparison failed to make the divergence legible.
• The solo build taught me where my instincts are strong (product framing, UX architecture, systems thinking) and where collaboration would have accelerated things (visual polish, frontend performance optimization).