I built Argus to help my dad research the AI infrastructure market

Following a question through the research

The question behind the app was more specific than “which AI stock is going up?” My dad wanted to explore companies and sectors connected to the buildout of AI infrastructure, including ones that might be receiving less attention. That meant the product needed room for semiconductors, memory, power, and other supporting businesses, rather than one undifferentiated list of technology stocks.

The workflow starts with a watchlist. From there, a company view brings together its price history, financial metrics, news, and SEC filings. A pullback view helps narrow the research list, while valuation comparisons add context about how a company looks against its peers. Bull and bear theses, conviction levels, and review dates preserve the reasoning behind an idea.

I wanted a person to be able to return to an idea and understand what had changed. A price movement, an earnings release, and an old research note tell different parts of the story. Putting them together was more useful than adding another chart.

Letting a real user shape the product

My dad kept asking for new symbols and ways to research different themes. Those requests changed the structure of the product. For example, I separated semiconductors and memory into their own bucket and removed data-center REITs when they no longer matched the research he wanted to do.

The same judgment applied to the AI infrastructure index. Highly speculative, pre-revenue names could distort its performance and make it less representative of the core theme. I kept those companies out of the core index while retaining room to research them separately.

These were product decisions as much as data decisions. The useful universe was the one that fit the research routine. It needed to be maintained as that routine evolved.

Building enough infrastructure to keep it useful

I used Python and Streamlit for the application, with SQLAlchemy connecting the data model to SQLite locally and PostgreSQL in hosted use. Scheduled GitHub Actions jobs refresh prices, filings, news, and macro data. The platform grew to track 53 companies across a 33-table model.

I started with free data sources and kept brokerage connections and trade execution outside the scope. The purpose was to help someone research and form a view. Explainable scoring, peer comparisons, and historical backtests fit that purpose better than an opaque recommendation.

I also explored return-prediction models. Their results were not strong enough to justify putting them into the product, so they stayed offline. A narrower historical downside screen proved more useful, with its limitations kept explicit. Building a model did not make it a feature the user needed.

The dashboard still needed a translator

As Argus became more capable, my dad still had to interpret the metrics and connect the evidence himself. More information had not automatically made the research easier to understand. That became the starting point for Argus Friend Brief.

The companion uses a local Gemma model to turn a company’s research evidence into plain-language briefs. It works from a bounded set of evidence, and factual claims have to point back to that evidence. Citation checks and a limited repair step help keep an explanation tied to what the system actually knows.

I made the public demo from a sanitized snapshot, with saved examples that people can inspect. Fresh generation runs locally. That let me share the idea without exposing personal research notes or making the demo depend on an always-running model server.

A project that keeps coming back to its user

The most useful outcome is that my dad comes back to Argus every day and continues to tell me what would help. The application has grown from a family request into a maintained research workflow, and the feedback has shaped both the data platform and the AI companion.

I developed it with coding agents, directing product scope, architecture, review, and verification. Over time, the difficult part became choosing which complexity was worth keeping. A new model, dataset, or page only helped if it made the next research decision clearer.