From a Working System to a Shippable Product
The aggregation pipeline, Story hierarchy, Big Pictures, Feed Formula, Moods, Publisher Report Cards, and Insights could all be demonstrated and tested. However, assembling those capabilities was not the same as having a product ready for public release.
The remaining work ultimately required nearly as much effort as building the original foundation. This involved improving data quality, resolving edge cases, strengthening performance, unifying the visual and interaction language, and ensuring that the system could operate reliably beyond the controlled environment of beta testing.
Ultimately, the complete product needed to deliver a reliable journey from opening the feed to understanding why something appeared, examining the surrounding coverage, navigating the larger narrative, and modifying the rules shaping the experience.
Scaling from 30 Publishers to More Than 850
The largest productization challenge was scaling the aggregation system. The original pipeline began with approximately 30 publishers before expanding to 100, then 400, and eventually more than 850. Each expansion gave readers a broader view of the news, but it also increased the volume and variability of information passing through every stage of the backend. Supporting 850 publishers was not simply the original prototype operating more times. The larger corpus changed how long aggregation took, how much memory the system required, how ranking signals behaved, and how much work the backend performed when a reader requested a personalized feed.
The personalized-feed request became the clearest example. To calculate a feed according to each reader's formula, the backend needed to consider every eligible article, apply the reader's signal weights and preferences, and return the selected items with their score explanations. This was manageable when the corpus was small, but request times expanded dramatically as the 72-hour article pool grew into the hundreds of thousands. In one production investigation, a personalized request took more than seven seconds while processing approximately 125,000 recent articles, with most of that time spent loading the complete corpus into memory and scoring it for that individual request.
The simplest solutions would have been to consider fewer articles, narrow the time window, restrict the publisher corpus, or serve a more generic pre-ranked feed. Each option would have improved performance by weakening something the product was intended to provide. Reducing the candidate pool would limit the breadth of reporting. Pre-ranking the complete feed would reduce the influence of the reader's formula. Restricting the corpus would move the product closer to the narrow selection available through existing aggregators.
I therefore focused on changing how the backend performed the work without changing which articles were eligible to appear. The scheduled aggregation pipeline already knew when the corpus had changed, so it began preparing shared feed data after each cycle instead of every request rebuilding the same understanding of the news. The scoring process was restructured around a smaller numerical score plane containing only the fields ranking actually required. And ranking was separated from rendering, so the backend could consider the complete corpus, select the winning items, and load the heavier content only for the results that appeared in the response.
The results were substantial. A representative response that had once required approximately 17 megabytes was reduced to roughly 142 kilobytes when compressed, and the redesigned request path brought server processing much closer to one second without narrowing the article pool or replacing the reader's formula with a generic recommendation.
In order to ensure durability during multi-user traffic, I deployed the service across multiple application workers and replicas so it could process concurrent requests without depending on a single running process, which surfaced its own trade-off: additional workers multiplied memory usage when each independently held a copy of the corpus, so what improved the speed of one request could make the overall service less stable. The smaller score-plane architecture helped resolve that tension by reducing what each request needed to materialize. This work was largely invisible within the interface, but it was essential to making the product's promises practical. Direct control would provide little value if every adjustment required a long wait, and broad aggregation would become a liability if the system could not process that breadth efficiently.
Building Operational Visibility
Releasing the application also meant I needed a way to understand how the backend was operating when I was not directly observing its output through the app. I created an administrative dashboard providing visibility into the aggregation and classification systems which allowed me to inspect feed-ingestion health, Story clusters, Big Pictures, publisher coverage, and topic classifications, investigate questionable groupings, review canonical-topic proposals, and run controlled quality experiments against the current corpus.
This was not an audience-analytics dashboard. It provided no access to individual reading histories, engagement profiles, or the private Insights information stored on readers' devices, and no way to manually reorder a particular reader's feed. Its purpose was to observe the news system itself. A limited set of explicit maintenance actions supported data quality, such as reviewing topic proposals or correcting the lifecycle of a Big Picture, and these were intentional and auditable rather than invisible editorial overrides of the ranking formula.
This operational layer was important to the project's broader philosophy. I had argued that institutions should be observable and accountable. Once I was responsible for operating an information system of my own, I needed the tools to apply that scrutiny to it continuously.
Becoming Mosaic News
As the backend developed into a stable system, the application needed to feel like one coherent product rather than a collection of experiments. Features had been developed at different times, often in response to different questions. Without a shared identity and design language, each capability risked feeling like its own application.
The name Mosaic News emerged from the product's central information architecture. A mosaic is composed of individual pieces that reveal a larger image only when viewed together, and the same metaphor described how the product organized the news. An Article represented one piece. A Story assembled the reporting surrounding the same event. A Big Picture connected those events into the larger narrative developing over time, while the Feed Formula gave readers control over which pieces reached them first.
The name therefore did more than label the product. It explained why its capabilities belonged together.
The product's north star became "See the whole picture." That promise applied both to understanding the news and to understanding the system distributing it. Readers could step back from one headline to see the surrounding coverage, inspect the publishers and perspectives behind it, and look into the formula determining why it appeared.
From one headline to the whole picture.
Reports from ABC News, PBS NewsHour, The New York Times, and others gather into Stories, and those Stories build the US-Iran Escalation Big Picture.
See how every side frames it.
Compare the Center, Left, and Right framing summaries for the same Story.
Trump Seeks $87.6B for Iran War Costs
✦ Summary updated June 25, 2026
Summary
The Trump administration requested $87.6 billion in supplemental funding from Congress on Wednesday, with $67 billion designated for the Department of Defense to cover costs from the Iran war (Operation Epic Fury). The request includes $21 billion for munitions, $17.3 billion for operational costs, and $12.1 billion for classified programs. The package also allocates $11.1 billion for U.S. farmers and $1.4 billion for Ebola response in Africa. The funding request came one day after Congress passed a war powers resolution to limit Trump's military authority against Iran. Democratic lawmakers signaled opposition, with Senator Patty Murray calling it a “disastrous war of choice,” while Republican support remained mixed.
✦ This summary is AI-generated and may contain errors or not fully capture all perspectives. Always verify important facts and refer to the original articles for accurate reporting. How we use AI →
See who’s covering the story.
See the 16 displayed publishers covering this Story: 10 Left, 3 Center, and 3 Right, for a 63% Left, 19% Center, and 19% Right mix.
Left
Center
Right
Follow the story as it unfolds.
See the Iran Nuclear Negotiations Big Picture above three overlapping Story chapters that progress from May 30 to July 2, 2026.
See the Blindspots on both sides.
Blindspot filters for Stories covered mostly by one side of the political spectrum. One example has 5 Left, 1 Center, and 13 Right rated sources; the other has 16 Left, 2 Center, and 1 Right rated source.
Showing Blindspot Story 1 of 2: Rubio Deports Walz-Pardoned Child Sex Offender
Every card explains itself.
See why the selected article appeared in the feed and inspect the plain-language signals behind its rank.
Trump Asks Congress for $88 Billion, Mostly for War With Iran
Your feed. Your formula.
See and adjust the visible signals that rank the feed.
Choose the feed you need in a tap.
Use Moods for an immediate feed-level lens while the Feed Formula continues to rank the Stories that remain.
Keep what matters in your feed.
Use the Topics tray to choose which sections are pinned and open the management destination for ordering and editing.
Pinned sections are paused while a mood is on.
Know who you’re reading.
Inspect the selected publisher's lean, factuality, credibility, ownership, history, and attributed sources.
The New York Times
Founded in 1851, The New York Times is an American daily newspaper based in New York City and published by The New York Times Company.
The Assessment
Overall, MBFC rates The New York Times Left-Center based on wording and story selection that moderately favors the left, and High for factual reporting due to proper sourcing and a strong correction record.
Political Lean
MBFC describes The New York Times as Left-Center. AllSides rates its news coverage Lean Left, while Ad Fontes places it in the Skews Left category. These independent ratings broadly agree that its news coverage sits left of center, though each uses a different methodology.
Factual Record
MBFC rates The New York Times High for factual reporting. Ad Fontes classifies it as Reliable, Analysis/Fact Reporting. Open either source to review its methodology and underlying record.
Ownership & Funding
The New York Times Company is publicly traded, while the Ochs-Sulzberger family controls the company through its Class B share structure. Its primary revenue comes from subscriptions, advertising, and licensing.
Ownership Type
Family-controlled public companyA publicly traded media company controlled through a separate class of family-held voting shares.
Quick Facts
History
Founded 1851The New York Times was founded in New York City in 1851 by Henry Jarvis Raymond and George Jones. Adolph Ochs purchased the newspaper in 1896, beginning the Ochs-Sulzberger family’s long stewardship.
Methodology
Ratings and assessments are attributed to Media Bias/Fact Check, AllSides, and Ad Fontes Media. Identity facts come from Wikipedia, while ownership and revenue details were normalized from The New York Times Company’s 2025 Form 10-K. These ratings are evidence to inspect, not ground truth.
Notice what held your attention.
See a private weekly reflection that connects the same Story topic to the visitor's broader reading patterns.
This week, your attention clustered around the and .
Your reading patterns belong to you.
Review an on-device-only picture of topic and source patterns, then return to feed control with better information.
Tap a topic to see how attention reached it.
Iran conflict
World
23%
Specific topics inside
Showing Insights view 1 of 2: Topic Landscape
Making Transparency Tangible
I developed the visual design around the same principles. The intended personality was to be “Teacher-like” by being information-rich but calm, approachable without becoming simplistic, and explanatory without being judgmental. This mattered for a product containing scoring systems, publisher assessments, political framing, and multiple levels of news context. The interface needed to make that depth available without reproducing the overload that had motivated the project in the first place. Rounded cards, soft backgrounds, restrained shadows, and editorial typography gave the news sufficient weight while avoiding the visual intensity common to engagement-oriented feeds, and data such as relevance scores and coverage counts received a consistent treatment so readers could recognize when the interface was showing evidence rather than editorial copy.
Apple's Liquid Glass design language became especially important to the product's identity. A surface that could be seen through provided a natural visual metaphor for a system with nothing to hide, but I did not want glass to become decoration applied indiscriminately. Within the content experience, glass was reserved for elements readers could inspect or control. A glass relevance badge explained why an item appeared. A glass publisher pill opened the source's Report Card. Glass framing and navigation controls moved readers between perspectives or levels of the Story hierarchy. The material developed a consistent meaning: transparency was something the reader could act upon.
Trump Asks Congress for $88 Billion, Mostly for War With Iran
Making that consistency real required repeated iteration between mockups, implementation, and user feedback, gradually consolidating the interface into a reusable component vocabulary. Publisher pills, relevance badges, cards, and controls behaved the same wherever they appeared, so something learned in one part of the application remained useful everywhere else. The product still maintained a distinction between reading and configuration: editorial surfaces emphasized the content itself, while settings and preference controls adopted a friendlier utility language that signaled the reader was now adjusting their system, with shared colors, geometry, and interaction patterns keeping the two worlds recognizably connected.
Defining the First Release
As the application approached release, the number of possible extensions continued to grow. The infrastructure made new features increasingly conceivable, but that did not mean every possible feature belonged in the first public version.
Alerts were the clearest example. Notifications could provide convenience and encourage readers to return, but building the complete experience introduced additional product and operational complexity. More importantly, alerts did not materially improve a reader's ability to inspect the news, control the feed, or preserve the privacy of their behavior. I deferred them until after release, and made similar decisions about other attractive additions that did not contribute directly to the core experience.
The first release was the smallest version I believed expressed the complete product system across providing transparency, agency, and privacy. Readers could understand the news in context, inspect why information reached them, control the system's behavior, investigate its sources, and privately reflect on their own consumption.
The final preparation included App Store positioning, privacy disclosures, and the public methodology explaining how the product's ranking, clustering, publisher information, and AI-generated summaries worked. The App Review process itself was comparatively smooth, and the application launched as a completely free experience with no in-app purchases.
Reaching this point changed the nature of my responsibility. During prototyping, a failure was primarily information for the next iteration. After release, the same failure could affect how someone understood a real event. The quality bar needed to account not only for whether the application functioned, but whether its systems, explanations, and design could operate responsibly without my supervision. With that bar met, Mosaic News was ready to leave beta testing and move to the App Store.
Chapter Summary
By this point, the product was no longer a collection of independent experiments or features and its capabilities had begun to reinforce one another. The remaining work involved improving data quality, resolving edge cases, strengthening performance, unifying the visual and interaction language, and ensuring that the system could operate reliably beyond the controlled environment of beta testing. Turning the working system into a shippable product would become its own substantial phase. The largest productization challenge was scaling the aggregation system. The original pipeline began with approximately 30 publishers before expanding to 100, then 400, and eventually more than 850. Supporting 850 publishers changed how long aggregation took, how much memory the system required, how ranking signals behaved, and how much work the backend performed when a reader requested a personalized feed.
Releasing the application also meant I needed a way to understand how the backend was operating when I was not directly observing its output through the app. I created an administrative dashboard providing visibility into the aggregation and classification systems which allowed me to inspect feed-ingestion health, Story clusters, Big Pictures, publisher coverage, and topic classifications, investigate questionable groupings, review canonical-topic proposals, and run controlled quality experiments against the current corpus.
As the backend developed into a stable system, the application needed to feel like one coherent product rather than a collection of experiments. The name Mosaic News emerged from the product's central information architecture. A mosaic is composed of individual pieces that reveal a larger image only when viewed together, and the same metaphor described how the product organized the news. The product's north star became "See the whole picture." That promise applied both to understanding the news and to understanding the system distributing it. I developed the visual design around the same principles. The intended personality was to be “Teacher-like” by being information-rich but calm, approachable without becoming simplistic, and explanatory without being judgmental. Apple's Liquid Glass design language became especially important to the product's identity as the material developed a consistent meaning: transparency was something the reader could act upon.
As the application approached release, the number of possible extensions continued to grow. The infrastructure made new features increasingly conceivable, but that did not mean every possible feature belonged in the first public version. The first release was the smallest version I believed expressed the complete product system across providing transparency, agency, and privacy. The final preparation included App Store positioning, privacy disclosures, and the public methodology explaining how the product's ranking, clustering, publisher information, and AI-generated summaries worked.