Homestretch/sample review
Example review
What a Homestretch review looks like
This is an example review of a real side project, shared with the owner’s permission. Names that would identify the product, repo, or owner are removed. It shows how we turn a GitHub repo + “done” description into a flat-tier recommendation.
Sample · not a live customer portal
Snapshot
- Stack: Python 3 / FastAPI backend, SQLite locally; plain HTML/CSS/JS frontend (charting library, no frontend build step); Docker Compose; optional AI “investigate” helpers.
- Size (at review): on the order of ~10k+ lines across backend + frontend, dozens of API routes, recent active commits.
- Features present: market overview / radar-style views, ticker analysis, discovery, watchlist, evidence/timeline UI, demo mode with synthetic data and a live mode that needs the operator’s own API key, settings UI with key test buttons.
Does it build, run, and test?
- Backend dependencies install cleanly. Backend pytest: hundreds of tests passed in a couple of seconds in our run (strong signal).
- Demo mode boots with the ASGI server; core JSON endpoints return synthetic data.
- Frontend node tests: mixed—some pass standalone; some need a running server (integration tests not fully documented); some fail because the test harness does not stub browser
alert. No CI was running the frontend suite. - Docker Compose looked sane (loopback bind by default); full image build was not exercised on our evaluation machine.
Security finding (explained plainly)
No committed production secrets showed up in history (good). Settings keys live in a local JSON file with restrictive file permissions—acceptable for a single-user self-hosted tool if documented.
Real issue: the API allowed browser calls from any website (Access-Control-Allow-Origin: *) while settings routes that save or test API keys had no application-level login. Binding the server to localhost helps, but it is not enough: a malicious page open in the same browser can still call http://127.0.0.1:… and, with open CORS, read responses. DNS rebinding is a related risk. Before calling the app “public/secure,” CORS should be limited to the app’s own origin, the Host header should be checked, and mutating settings routes should require a local admin token (plus docs/tests for that threat model).
The project’s own README already warned it was not production-ready—accurate.
Gaps vs. a typical “done” ask
| Ask | State at review |
|---|---|
| Self-host with your own data/API keys | Mostly there (Docker, env, Settings) |
| Unusual-activity style discovery with evidence | Core flows present |
| Optional AI research helpers | Present; one transport path experimental |
| Pixel-parity with a larger production product | Partial—some modules explicitly out |
| Reliable historical analysis / quant engine | Not there—needs real baseline/backend work (product/quant, not a flat polish) |
| Secure local UX | CORS / no-auth settings issue above |
| Open-source community packing | Missing LICENSE, CONTRIBUTING, SECURITY.md, CI, release tags, etc. |
Fit decision
An open-ended “mirror the full production product + invent reliable historical analysis + add undefined new features” ask is out of scope for any flat tier. A trimmed public v1.0 release scope fits Plus ($299): the codebase was already roughly ~80% and well tested on the backend; remaining work is hardening, release plumbing, community scaffolding, and a deploy-ready PR handoff (DEPLOY.md; customer deploys). Anything beyond that → custom quote after v1.0.
In scope for Plus ($299)
- Security hardening: same-origin CORS; Host allowlist; local admin token on mutating settings routes; settings file permissions; SECURITY.md with a short threat model.
- Fix failing frontend tests (stub
alert, document/auto-start server for integration tests) and a singlemake test(or equivalent) entrypoint. - CI: backend pytest + frontend tests + Docker build on PRs.
- Release path: tagged v1.0, changelog, documented upgrade via rebuild; optional container registry publish.
- Community files: LICENSE (customer’s choice), CONTRIBUTING, Code of Conduct, issue/PR templates, ROADMAP seeded with out-of-scope items.
- Docs pass: one clear quickstart (demo → live with the operator’s own key), troubleshooting; move scattered in-code notes into docs.
- Verify clean install from scratch in Docker (demo). Live-mode smoke tests use mocks on our side; the customer runs any real-key checks themselves after merge.
- DEPLOY.md with one-command steps for their chosen platform and required env var names (never values).
- Optional when feasible: temporary demo preview on our infrastructure (synthetic data only), removed after handoff; and/or notes for publishing the static demo build.
Out of scope (custom / roadmap)
- Real historical analysis engine / backtesting replacing synthetic gates
- Porting large extra modules or pixel-parity with another production UI
- Open-ended “meaningful new features”
- Multi-user auth, managed hosting, or us deploying into the customer’s cloud/DNS accounts
- Trading-signal accuracy claims or financial/compliance review
- Ongoing maintenance or community management after delivery
Effort note (for this example)
On the order of one to two agent-days of implementation plus review; delivery measured in a few business days once paid—subject to the customer providing whatever keys they want smoke-tested. Risks include third-party API entitlement differences and scope creep from vague “make it like production” language.
Founding offer: limited spots. See current availability on the home page.