3
12 Comments

My marketing never knew what my forecast said. So I built something that does.

I run two businesses and have a full-time job on top of that.

For a long time, my forecast lived in one app, and my marketing plan lived in another. They never talked. My marketing had no idea whether revenue was up or down, what the numbers were actually predicting, or what to focus on next. It was built on guesswork, not data.

I didn't have time to manually connect the two every week. So I built YFinanceAI. It forecasts your numbers, then builds your marketing plan from that same forecast, and writes your content from the same data too. Nothing gets lost translating between apps.

It's live now at yfinanceai.com. I'll be posting updates here as I go: what's working, what's breaking, what people are saying.

If your marketing and your numbers don't talk to each other either, I'd genuinely like your feedback.

on September 8, 2026
  1. 1

    A very interesting problem, because the real value isn't just in connecting the forecast to marketing, but in whether the forecast actually changes what gets prioritized.

  2. 1

    One useful implementation detail might be to make each forecast a dated snapshot and attach the campaign or decision it informed. Then you can compare the forecast at decision time with the eventual outcome, instead of only reading the latest forecast after the fact. Even a simple “forecast → action → result” log would make the connection measurable and help separate better timing from hindsight.

  3. 1

    I've watched a few forecast tools die on this: predictions never get checked against reality, so nobody trusts the plan built from them. One bad forecast poisons everything downstream - make the miss visible: log what you predicted, compare after the period, let the calibration gap drive the next plan.

  4. 1

    The disconnect between financial data and marketing is a real problem. I like the idea of keeping the forecast, strategy, and content tied to the same underlying numbers instead of treating them as separate workflows.

  5. 1

    MananShah's point about logging the exact moment is critical - your measurement latency determines what you can actually prove. If you wait a week and try to remember whether a forecast changed your mind, you've already lost the specificity. But if you capture it the moment someone overrides their instinct for the forecast, you have verifiable proof the tool actually changed behavior. That's the difference between "this feature exists" and "this feature drives decisions". Measurement timing is how you distinguish between coincidence and causation.

  6. 1

    Aryan's question and your answer map onto something a few of us have been calling declared vs. observed this week: "connects the data" is observed, you can watch it happen. "Changes marketing decisions" is currently declared — it's what the product is built to do, not yet what you've watched it do. Good instinct separating those explicitly instead of letting the proven part lend credibility to the unproven part, which is an easy thing to do by accident.

    The signal you're asking users for — "did the forecast change a call you made" — is the right thing to track, and I'd suggest logging it as its own field the moment it happens, not something you reconstruct from memory later when writing an update post. The exact moment someone overrides their gut because of the forecast is going to be easy to lose track of once you have more than a couple of users doing it.

    1. 1

      The declared vs. observed framing is exactly right, and it's a good catch. Easy to let the proven half unintentionally borrow credibility for the part that's still unverified.

      Taking the logging suggestion seriously too. I'll build a simple flag for that exact moment, someone overriding their instinct because of the forecast, rather than trying to piece it together after the fact from a conversation or a support message. That kind of signal is too specific to trust to memory.

      Appreciate you naming the distinction clearly. I'll follow up here once I actually have that data instead of just the intention.

  7. 1

    Does anyone using YFinanceAI actually change what they market or when they market it based on the forecast, or is the main benefit just having the data connected?

    1. 1

      Right now, yes, the main proven benefit is the data being connected instead of you manually reconciling two different apps. That alone removes a real daily friction point.

      The bigger shift, marketing decisions actually changing based on the forecast, is exactly what it's built to do. If your forecast shows a dip next month, the plan reflects that instead of running blind to it. I'm actively gathering real usage data on how much that changes people's actual marketing decisions, and I'll be sharing what I learn here as it comes in.

      If you try it, I'd want to know specifically whether the forecast changed a call you made, that's the exact signal I'm looking for.

      1. 1

        That’s a useful distinction between the proven and unproven value. If you’re open to it, what’s the best email to reach you on?

        1. 1

          Appreciate that, glad the distinction was useful. You can reach me at info@yfinanceai.com happy to walk you through it directly or just get you set up and hear what you find.

          1. 1

            Thanks! I’ve just sent it over.

            Looking forward to hearing your thoughts whenever you have a chance.