# Build brief — a focused alternative to StocksBrew

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

## Context

**StocksBrew** — Current US-stock calls, targets, watchlists, and price or earnings alerts. It currently costs $9/mo.

A personal stock-research cockpit is very buildable, but StocksBrew's useful current calls depend on continuously maintained market, filings, news, and alert pipelines. A DIY version can make its evidence and rules explicit; it will not inherit the service's coverage, refresh reliability, or editorial judgment.

This brief describes a focused, single-operator replacement for the part of StocksBrew 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

Fetch end-of-day prices, SEC filings, and selected RSS news for a watchlist, score each stock with transparent rules, and notify the owner when a price or earnings condition changes.

- Build a focused single-user workflow with real persistence, search, and export.
- A responsive interface with real empty, loading, success, and error states.

## Requirements

### Functional

- SEC EDGAR data.
- RSS news sources.
- Scheduled job.

### Data and integrations

- Market-data API key.
- LLM API key.

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 me a personal US-stock research cockpit to replace StocksBrew. Requirements:

- Node 22 + Express + better-sqlite3 + node-cron, server-rendered pages on
  localhost:8090, no frontend framework.
- watchlist.json holds my tickers; npm run refresh and a daily 7am cron pull
  end-of-day prices from Alpha Vantage (key in .env), filings from SEC EDGAR
  (no key needed), and items from a curated RSS list in sources.json.
- Score each stock with transparent rules in one rules.js file (price vs 50/200-day
  average, new 10-K/10-Q/8-K filings, earnings-date proximity) and show an
  add/hold/trim stance with the exact rule hits that produced it.
- Every summary line cites the filing or article URL and its timestamp; nothing
  uncited, nothing invented.
- Alerts: per-ticker price threshold and earnings-date reminder, sent by email over
  SMTP creds in .env.
- Rate-limit and cache all external calls (Alpha Vantage's free tier is 25
  requests/day, plan the refresh around it), dedupe news items, and mark stale
  data visibly.
- Dashboard: one watchlist table with price, stance, last-filing link, and next
  earnings date; one detail page per ticker with score history.
- SQLite tables: tickers, price_snapshots, filings, news_items, scores, alerts.
  One file I can back up by copying it.
- No accounts, no telemetry, everything local except the documented API calls.
- Out of scope: intraday data, brokerage connections, trading, and editorial stock
  calls. Put a clear not-investment-advice notice in the README along with setup,
  API limits, and the cron line.

## 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:

- Maintained stock coverage and editorial calls.
- Intraday data quality and provider reliability.
- Managed earnings and price alert delivery.
- The product's target-price methodology.
- The useful dataset is owned, accumulated, or expensive to reproduce.
- Reliability at the vendor's scale is an operations problem, not a prompt.

## 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: high. No independent one-shot implementation is linked yet.

## Prior art

Working open-source software you can read, fork, or borrow from before starting:

- [OpenBB Platform](https://github.com/OpenBB-finance/OpenBB) — Open-source financial research platform with market-data integrations

---

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