The following links may be helpful to you:

Additional or alternative investors in Germany can be found on the webpages of BVK e.V., of the German state-owned bank KfW or of the German Business Angel Association An overview of international investors is provided by Invest Europe and by the European Business Angel Association. Funds, that primarily invest in social matters are for example Bonventure or Ananda. Several cities and large companies have accelerators and incubators where founders can get support in starting their business. An overview can be found here: https://www.eu-startups.com/2016/02/startup-accelerators-in-... To get additional support in founding a company please have a look at the Enterprise Europe Network. • Webpages like www.entrepreneur.com or www.eu-startups.com offer some insights and tips when starting a company and writing a business plan. To find a co-founder there are several start-up weekends all over Europe and platforms like www.cofounderslab.com or www.founder2be.com.

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.

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?

Got to love the relational model. Learned about fan traps in data modelling course at uni in the early 80s

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.

Thanks!

I validated the inputs by working backward from actual Lender Term Sheets. I looked at what lenders contractually require to underwrite a deal (like Origination Points or strict LTC caps). If a variable was a "deal-breaker" for funding, I made it a primary input; everything else got tucked into "Advanced" settings to keep the UI clean.

Good luck with InvestBot!

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?