# Build brief — a focused alternative to MonkStreet

> **Verdict:** Partly, if you narrow it · **Buildability:** 36/100 · **Category:** Personal Finance
> **Source:** https://www.canitbevibecoded.com/monkstreet
> Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from MonkStreet. Verify current pricing and capabilities before acting.

## Context

**MonkStreet** — Subscription investing service that sells algorithmic stock signals and quant-flavored market research. It currently costs $200/mo.

The software half of a signals service is genuinely small: pull daily bars, compute factors, rank a universe, backtest with walk-forward windows, email yourself the top names. An agent will get you that in a focused implementation, and it will look uncomfortably similar to what you are paying for. What you cannot one-shot is point-in-time fundamentals, survivorship-bias-free universes and clean corporate actions, which is exactly where homemade backtests turn into fiction that says 40 percent a year. The unverifiable part is whether the paid edge is real, because no subscriber gets to audit it either. So build the harness, use it to think, and do not confuse a green equity curve on free data with alpha.

This brief describes a focused, single-operator replacement for the part of MonkStreet that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.

## What you are building

Pulls daily price data for a chosen universe, ranks it with momentum and value style factors, backtests the ranking with walk-forward rebalancing, and emails you the current top and bottom names.

- Import transactions, categorize spending, and forecast cash flow privately.
- A responsive interface with real empty, loading, success, and error states.

## Requirements

### Functional

- Python 3.11 and a machine that can run a nightly job.
- Enough statistics to distrust your own backtest.

### Data and integrations

- A market data source with an API key, free tier is fine for daily bars.
- An SMTP account or similar for the daily digest.

Each of these needs a real account, credential, or quota. Set them up before writing feature code.

### Non-functional

- Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.
- Security: server-side secrets, validated input, and no credentials in the client bundle.
- Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.
- Portability: the operator can export their data and leave without losing it.

## Implementation brief

Build a local quant research harness for a single user. No accounts, no hosting, no telemetry.

Stack: Python 3.11, uv for deps, DuckDB for storage, pandas and numpy for math, Streamlit for the UI, plain SMTP for the daily digest. No cloud services, no Docker, no web framework.

Data: fetch daily adjusted OHLCV for a ticker list in universe.txt from one provider behind a single fetcher module, so it can be swapped. Cache every response into DuckDB and never refetch a date range you already have. Provider key and SMTP creds live in .env, loaded with python-dotenv, and .env is gitignored with a .env.example committed.

Build these pieces:
1. ingest.py: incremental daily bar download into DuckDB, idempotent, logs how many rows were added per ticker.
2. factors.py: compute 12-1 momentum, 60-day volatility, 200-day trend filter, and a simple value proxy from whatever fundamental fields the provider gives for free. Each factor is a pure function of a price frame, cross-sectionally z-scored, missing data handled explicitly rather than dropped silently.
3. backtest.py: monthly rebalance, long the top decile of a weighted factor blend, equal weight, configurable transaction cost in basis points, walk-forward so factor weights are fit only on data before each test window. Output CAGR, max drawdown, Sharpe, turnover, hit rate, and a per-year table. Print a loud warning that the universe is survivorship biased and the fundamentals are not point-in-time.
4. app.py: Streamlit page with the equity curve, the yearly table, the current ranked table, and a slider for factor weights that re-runs the backtest.
5. digest.py: a script for cron that emails today's top 20 and bottom 20 with their factor scores.

Out of scope: intraday data, options, order execution, broker integration, portfolio accounting, tax lots, auth, multi-user anything.

Include pytest tests for the factor functions and for one known-answer backtest on synthetic data. Write a README that states plainly what the data limitations invalidate.

## Delivery standard

- Inspect the repository first, then write a short implementation plan before writing code.
- Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.
- Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.
- Include responsive layouts plus genuine empty, loading, success, validation, and failure states.
- Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.
- Add structured logs around every external call and return actionable errors without leaking sensitive details.
- Write unit tests for the core logic and one automated test of the main user journey.
- Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.

## Acceptance criteria

- [ ] A clean install starts the app using only the README and .env.example.
- [ ] The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.
- [ ] Invalid input, missing configuration, provider failure, and an empty database each have a usable state.
- [ ] The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.
- [ ] Tests, type checking, linting, and a production build all pass with no ignored failures.
- [ ] No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.

## Non-goals

Do not build these, and do not claim to have replaced them:

- Point-in-time fundamentals and delisted tickers, so your backtest quietly assumes the losers never existed.
- Clean handling of splits, dividends, mergers and index reconstitutions.
- Whatever research process, however good or bad, sits behind the paid signal.
- Someone else's conviction to blame when a position goes against you.
- Any institutional data feed: short interest, filings parsing, tick data, borrow costs.

## What you still own after launch

- Secure credentials, rotate secrets, and handle provider rate limits.
- Run migrations, backups, restores, and dependency updates.
- Test the critical journey after every model, API, or hosting change.
- Monitor failures and fix the edge cases a first prompt will miss.

## Risk

**High consequence.** Use this as a prototype or personal aid. Keep a qualified human and an established provider in the loop for consequential decisions.

Editorial confidence in this assessment: low. No reviewed project implementation is linked yet.

---

Generated by [Can It Be Vibe Coded?](https://www.canitbevibecoded.com) · Full report: https://www.canitbevibecoded.com/monkstreet
