investbot

Nice work. A lightweight confusion matrix tool is surprisingly hard to find.

Technical question: did you consider support for class imbalance scenarios (e.g. thresholding or cost-weighted confusion matrices)? In many real datasets, F1/accuracy hide useful signal unless you vary the decision rule.

Clean implementation, and good call on keeping it simple.

That makes sense. We use a similar "work backwards from constraints" approach, but with portfolio rules instead of lender terms.

For us the closest analog to "deal-breaker variables" are things like: - max drawdown thresholds - concentration caps - volatility ceilings - event gating (earnings, macro events)

Those are the points where a normal investor violates their own process under stress, so we surface them as primary controls. Things like turnover or sector caps end up in “Advanced” for the same UX reason you mentioned.

Curious - did you iterate on how much to hide in Advanced vs surface by default, or did the term sheet mapping give you a clean partition from the start?

Absolutely, if your moat isn't the code, but a deep understanding of a specific problem and speed. We're building InvestBot for investors who lose money not because of bad stocks, but because they panic and break their own rules.

Big companies don't copy this because:

The problem is too niche and behavioral (not "how to get returns," but "how to enforce your own discipline").

Their game is scale; ours is depth of trust. We see this with our 200+ beta users: 64% ran portfolio scans more than twice, 12% immediately said they'd pay $20-30/month for rule monitoring. That's not a forecast—it's existing, paying demand for discipline.

Speed vs. bureaucracy. Our engine, which analyzes thousands of historical scenarios against user-defined constraints, was built by two people in 5 months. A large corporation would still be aligning on a roadmap in that time.

The takeaway: Code is a commodity. The real moat in 2026 is speed, focus on a real pain point, and the ability to turn users into a community that trusts your approach more than a magic pill.

This is an excellent breakdown of a subtle but critical modeling problem. The analogy to event-driven architectures is spot on.

We face a structurally similar challenge in investment simulation, but with time-series data. A user's portfolio is the central hub ("event broker"), and historical market events (drawdowns, volatility spikes, earnings) are the producers/consumers. If we model relations naively, we lose which specific historical regime caused a given rule violation.

Our solution aligns with your "Solution 1: More specificity": we pre-compute and tag regime-specific metrics (e.g., "max drawdown during 2020 Q1", "volatility during 2018 Fed hikes"). This allows the engine to answer "why was this stock excluded?" with a precise historical scenario, not just a generic violation.

Question: In your experience, is there a performance/readability trade-off threshold where adding this specificity (like your firewall rules or our regime tags) becomes counterproductive for the diagram (or system) comprehension?

Nice work on making the hard money loan math transparent — that's often a black box. I'm building a tool in a similar "rational decision-making" space, but for stock portfolios (InvestBot). Your approach to breaking down complex financial terms into interactive inputs is exactly the UX challenge we face with risk constraints like max drawdown and concentration caps. Question from one builder to another: How did you validate which specific loan parameters were most critical for users to control? We're constantly prioritizing which risk rules to expose first.