Timefire
AI forecasts for every S&P 500 stock, backed by a public history anyone can check.
Product: Timefire ranks every S&P 500 stock each trading day. Before the market moves, we lock the full set of rankings so it cannot be changed later. Ten trading days later, we compare every forecast with the official closing price and publish both the wins and the misses. Past results are free to inspect; current forecasts are available through early access.
Other than training the model, I led product strategy, organized the content, created the brand and user experience, built the design system and product interface, and prepared the launch. My job was to turn the model's evidence into a product that a skeptical reader could understand, test, and use.
The product problem
Any forecasting product asks people to believe two things: that its model is useful and that its published history is honest. Timefire could not prove either by simply claiming accuracy or grading its own results behind closed doors. People needed to be able to check both claims for themselves.
We began with individual investors who question financial claims and are comfortable examining evidence. They could try the product without a salesperson, while the same public record could later support a professional investment review. With no testimonials or long customer history, the product itself had to persuade. Within one minute, a visitor should understand what we forecast, what the public record proves, what remains uncertain, and whether current forecasts are worth joining the beta for.
The wrong first answer
We solved the trust problem first—and overdid it. The original site focused almost entirely on the public record, timestamps, and verification. Across six main pages, the word “AI” never appeared. The navigation offered four ways to inspect evidence but no clear explanation of the product. A visitor could learn how a forecast was locked without learning what the model produced or why tomorrow's rankings mattered.
We soon realized that we had made the evidence the subject. The correction was not to weaken the proof, but to put it in the right role. The forecasts are the product; the public record explains why someone should believe them. That distinction changed the product, site, and launch plan.
Putting the product first
I reorganized the experience around three questions: What do I get? How does it work? Can I verify it? First, show the daily ranking of every S&P 500 stock. Next, explain what the model reads, where it performs well, how it was tested, and when it performs poorly. Then let the public record support those claims. Only after that do we ask someone to join.
Two rules keep the story honest. We judge the full day's rankings, not one hand-picked stock. Each day's complete set is compared with the S&P 500 over the same ten trading days, so an isolated winner never becomes the headline. Figures that change over time appear only on pages that clearly show their date.
The business model follows the same logic. Past results remain free so anyone can judge the record. Current forecasts, search, alerts, and access for other software make up the early-access product.
Help readers check the proof
Trust does not come from one screen. Each part answers a different question: What did the model predict? How has the complete history performed? Was this forecast locked before the result was known? Can I check the proof myself? Readers can stop when they have enough confidence or continue into the technical details.
Make the history easy to read
The public record treats each trading day as one complete, accountable set. Every finished day shows its date, how its forecasts performed compared with the S&P 500 over the same ten-day period, and whether they finished ahead or behind. A bar represents every day in order, so a missing day appears as a visible gap. Ahead is blue and behind is gray—not green and red—because this is a historical record, not a celebration of profit and loss.
Each day also has a permanent page with the original locked data and step-by-step proof. A reader can cite the underlying evidence instead of relying on a summary.
Let readers test the proof
The verification page performs five checks in the reader's browser. It downloads the original locked file, calculates its unique digital fingerprint again, verifies who signed it, confirms when it was recorded on Bitcoin, and checks that it could not be opened early.
The key interaction is “Show me what failure looks like.” It changes one tiny piece of the file on the reader's device and repeats the checks, allowing people to see the proof fail before trusting it when it passes. Timefire does not ask a page it created to certify itself.
Explain the model—and its limits
The model page explains what each daily ranking contains, what information the model uses, where it performs well, how we tested it, and when it performs poorly. I turned those findings into an illustrated explanation that stays clear without hiding uncertainty.
Four drawings appear beside the ideas they explain. Animation shows the order of events but never carries essential meaning, and readers who reduce motion see the finished drawing immediately. Publishing weaker experiments beside the stronger result was the most credible choice. Candor does more here than another claim about confidence.
Show why the record matters
A public, fixed rule turns each day's locked rankings into simulated trades, with no hand-picked stocks or later changes. Every simulated trade links back to the day that produced it, connecting the forecast history to a result a buyer can understand. Each page's numbers and charts come from the same saved set of data, so they cannot show conflicting results.
A weekly sample shares six forecasts chosen by the same rule before their results are known. Each week joins the permanent record instead of disappearing after a good result. It gives people enough of the product to evaluate without pretending that one stock proves the model.
Keep every part consistent
An outdated number, an inconsistent claim, or a mismatched graphic can weaken trust as much as a broken screen. I built the brand and publishing process with the care of a newspaper of record: a clear order of importance, exact figures, limited use of color, and automated checks that turn design decisions into rules the site must follow.
Brand what the product does, not what it promises
“AI forecasts, sealed and graded” describes what Timefire does without promising a return. The visual system follows the same principle: explain the claim clearly, then present the supporting details quietly. Each screen leads with one plain-language statement, followed by precise evidence in a typeface designed to keep numbers aligned.
The mark draws literally from Timefire's name: a turquoise blade and its shadow form a modern sundial, while the blade also suggests a flame. Time becomes the witness—the forecast makes a claim, and the public record reveals whether it was true. The mark reflects our verification process: every forecast is locked before the market moves, then judged in public.
Check the design system before release
The design system separates decisions into four layers: shared values for color, spacing, and type; reusable text styles; reusable parts such as buttons and cards; and layout rules for individual pages. Its reference page is built from those same values and checks what the browser actually displays, so the documentation cannot quietly disagree with the product. Automated checks block stray one-off styles, missing page rules, and style files loaded in the wrong order.
The design x-ray makes those hidden rules visible on the real page. An overlay shows which set of rules controls every element and flags missing rules, one-off styling, duplication, and patterns that appear on only one page. When a pattern should become reusable, I compare the page before and after at three screen sizes in both the day and night views. It moves into the shared system only when the browser reports no visual change.
This makes the design system more than a gallery of reusable parts. It becomes a set of checks that can stop a flawed release. A small team can improve the underlying code with evidence that the product readers see has not changed.
Keep every published number consistent
The public site is built as ready-to-serve web pages. Numbers from Timefire's data source are written directly into those pages, so readers see the same figures in the text and charts as soon as the page opens. During the daily update, the homepage chart and its headline figures are created from the same saved data, preventing them from disagreeing.
Share images use the same colors and mark as the site. General pages avoid figures that change frequently because social platforms may store an old preview for days. Pages for completed forecast days can show dated results because those figures will never change. The evidence stays accurate wherever someone encounters it.
Design for people and software agents
Timefire treats people and software agents—automated tools that read websites and answer questions—as readers of the same public record. Every standard web page has two matching versions: a plain-text file that software can read directly and a simplified Agent page where a person can inspect exactly what an agent receives. A visible Human/Agent control and three lists help agents find every available page.
These are not separately written sites. After the standard pages are built, one publishing step finds every public page and creates both agent versions. The human page and agent versions take dates, figures, explanations, and warnings from the same saved evidence. The Agent page displays the generated plain text instead of adding another copy that could drift. Nothing goes live until the complete set passes its checks; then the old set is replaced all at once.
If a human page and its agent versions are incomplete, disagree, or could expose a still-hidden forecast, the release is blocked. Every meaningful section must appear in the agent version or link to the complete underlying data. Automated tests catch missing pages, old facts, information that should not be public, broken links, and disagreements between versions. Two public services—the API and MCP server—let other software ask Timefire for data. Both return a forecast only after its result is known. Asking for fewer results cannot reveal a stock from a forecast that is still locked.
Human visits and agent requests are counted separately. This prevents automated traffic from inflating the number of people who move toward signup, while still showing which versions agents use. The principle matches the forecasting product: readers should not have to trust a claim when they can inspect the evidence themselves.