InvestorID: AI Investment Intelligence for the IDX
A daily 900+ IDX stock pipeline running serverless on Cloud Run + Supabase, at ~$0.10/month per the README's cost table

- Agentive Labs product
- Data Platform
- Indonesia
- March 28, 2026
The problem
This project grew out of a common personal problem: emotional trading decisions, no systematic screening process across 900+ IDX-listed stocks, and no clear entry/exit strategy. Professional tooling for this is unaffordable for small retail investors. InvestorID was built for a single swing trader with a six-month to two-year horizon, to replace emotional decisions with rule-based, data-driven investing.
What we built
A serverless, event-driven platform that runs every day after the market closes:
- Cloud Scheduler triggers the data fetcher job at 17:30 WIB, pulling EOD data from yfinance and the IDX website, then computing technical indicators (RSI, MACD, MA, Bollinger, ATR).
- An anti-gorengan quality gate filters with ten mandatory checks; manipulated or distressed stocks are blocked before multi-factor screening with composite scoring begins.
- The AI analyst analyses the top stocks through a rate-limited Cloud Tasks queue: Gemini Flash for technical summaries (free tier), Claude Sonnet for deep fundamental analysis.
- The alert service sends the daily report and buy/sell signals to Telegram.
- A FastAPI gateway with 28 endpoints serves screening, stocks, portfolio, and analysis.
Engineering decisions
Serverless down to zero when idle. All compute runs as Cloud Run Jobs that exist only while triggered and scale to zero afterwards; the database sits on Supabase’s free tier. The README’s cost table totals roughly $0.10 per month.
Pragmatic clean architecture, not full DDD. Thin service entry points under 50 lines; pure-Python business logic with no database imports; repositories handle data access. The dependency rule runs one way and never reverses, so the screening logic can be tested without a database.
Full type discipline. mypy in strict mode, Ruff for lint and format, pytest for unit and integration tests, and CI runs all three on every PR. LLM model names live in env configuration, so a model update from Google or Anthropic touches no code.
Status
Documented as deployed to GCP’s asia-southeast1 region with CI/CD from GitHub
Actions (merging staging into main builds and deploys every service). The
repository is public and MIT-licensed:
github.com/ridwanspace/investment-app.
Does your team face a similar problem?
Tell us about the workflow and its constraints. We start with a scope we can describe and verify.


