# Build brief — a focused alternative to Harvey

> **Verdict:** Not faithfully · **Buildability:** 6/100 · **Category:** Legal
> **Source:** https://www.canitbevibecoded.com/harvey
> Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from Harvey. Verify current pricing and capabilities before acting.

## Context

**Harvey** — An enterprise AI assistant for legal work: research, drafting, review and diligence across a firm's document estate.

You can absolutely build a local RAG assistant over your own PDFs with a focused implementation, and for reading your lease or a vendor contract that is genuinely enough. Harvey is not sold on that loop. It is sold on trained-and-evaluated legal workflows, curated case law and regulatory sources under license, deployment that survives a law firm's security review, and the ability to put a name behind an output that a partner will bill against. The thing you cannot one-shot is the confidence to rely on the answer, which in legal work is the entire product. A personal replacement is fine for personal stakes and dangerous the moment money or a filing depends on it.

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

Indexes a folder of your own contracts and PDFs locally, then answers questions about them with quotes and page citations so you can check every claim yourself.

- Draft templates, compare documents, and summarize case material for human review.
- A responsive interface with real empty, loading, success, and error states.

## Requirements

### Functional

- Your own documents: no licensed case law, no statute databases, no primary sources.
- Python 3.11 and a willingness to read the cited passage rather than trust the summary.

### Data and integrations

- An LLM API key, or a local model via Ollama if you would rather nothing leaves the machine.

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 document Q&A tool for my own contracts and PDFs. Python 3.11, single project, no web framework, no accounts, no telemetry.

Stack, no alternatives:
- CLI with Typer
- pypdf for text extraction, page numbers preserved
- SQLite with the sqlite-vec extension for vector storage
- OpenAI API for embeddings and answers, key from .env via python-dotenv, plus an --ollama flag that swaps to a local model at http://localhost:11434

Commands:
- ingest PATH: walk a folder, extract text per page, chunk to roughly 800 tokens with 100 overlap, store chunk text plus doc name plus page number, embed and index. Skip files already ingested unless --force.
- ask "QUESTION": retrieve top 12 chunks, then answer with an LLM that is instructed to answer only from the provided chunks and to say "not in these documents" when the answer is absent. Every claim must carry an inline citation like [contract.pdf p.4].
- sources "QUESTION": print the retrieved chunks verbatim with file and page, no LLM, so I can read the raw text.
- docs: list ingested files, page counts, chunk counts.

In scope: local-only storage in ./index.db, deterministic chunking, a --model flag, plain text output.
Out of scope: web UI, multi-user, cloud sync, any bundled case law or statute data, any attempt to cite external legal sources.

Print a one-line disclaimer after every answer: this is a reading aid over my own files, not legal advice, verify each citation.
Include a README with setup, .env.example, and a short section explaining that answers are only as good as the documents I ingested.

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

- Licensed primary law: case law, statutes, filings and regulatory corpora you cannot legally scrape together.
- Workflow products that have been evaluated by actual lawyers: diligence checklists, redline review, deposition prep.
- Firm-grade deployment: SSO, data residency, retention controls, audit logs, security questionnaires answered.
- Anyone to blame. Your hallucination is your malpractice exposure.
- Integration into the systems legal work actually lives in: DMS, iManage, Word, the review platform.

## 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: medium. No reviewed project implementation is linked yet.

---

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