How to Build a True-Crime Case-Tracking Website From Scratch

A complete blueprint: architecture, data model, human-in-the-loop AI production pipeline, operating economics, and monetization

There is something rare on the internet: a site that built a genuinely engaged audience — roughly half a million pageviews a month at its peak — and still closed. Not for lack of readers. Homicide Watch D.C. closed because keeping every case file current cost roughly one full-time reporter's salary, and when its founders relocated, no local partner would fund that role. The audience was there. The economics were not.

That gap — between what readers want and what it actually costs to keep it current — is the problem this blueprint solves. Not with a content strategy. With an operating model: a structured case database, a human-in-the-loop AI pipeline, and a per-case update cadence that is honest about what one editor can actually sustain.

What follows is the full architecture: the data model, the nine-prompt production pipeline, the privacy and accuracy gates, the operating economics, and the monetization layers — for a site that publishes living case files, not articles.

1. Why This Website Exists

Most true-crime content on the internet is entertainment repackaged as journalism: a script rewritten into a blog post, built for shock value, published once, and rarely updated. It tells you what happened. It rarely tells you what happened next — whether the defendant was convicted, what the sentence was, where the money went, or how the case actually resolved. A case-tracking site doesn't publish stories — it publishes living case files. Every case gets a permanent page that gets updated at every hearing, filing, and verdict, for as long as the case is active. The reader doesn't get a one-time article; they get a resource they can bookmark and return to.

Three groups feel this gap directly: readers following a specific case (families, local communities, true-crime audiences) currently piecing together updates from scattered local news; journalists and researchers who need a reliable timeline and primary-source trail instead of re-reporting from memory; and businesses that need structured legal-outcome data — insurers, compliance teams, documentary and podcast producers — who currently rely on legal databases built for lawyers, not for narrative case-following.

2. The Market Reality

It would be convenient to say no one is covering this space. That isn't true, and claiming it would undermine the credibility of everything that follows. The market is fragmented, not empty. Existing products tend to optimize for different jobs:

• Courtroom coverage as media — live trial video, legal commentary, and true-crime programming at real scale. Law&Crime, which acquired Court TV in February 2026, operates a flagship YouTube channel with more than 7 million subscribers and 6 billion video views. This is a video-first media business built on live and archival footage, not a per-case tracking product.
• Structured criminal-justice data at civic scale — AI-assisted tracking of every homicide in a jurisdiction from act to resolution, with a public-facing database (DC Witness's model). This is architecturally the closest existing product to what this blueprint describes.
• Narrow-scope, primary-source-only tracking — following one specific docket category (e.g., a defined set of federal lawsuits) with a strict "links to filings, no commentary" policy and a free/paid newsletter split (CourtWatch.news).
• Raw court records with no narrative layer — commercial legal-data platforms (e.g., UniCourt) built for lawyers and researchers, not general readers.

Among the models examined for this blueprint, none fully combines readable narrative + structured, filterable case data + scheduled, systematic update-checking in one consumer-facing product. That combination — not an empty market — is the opening. The honest framing is: the opportunity is in the combination, not in the absence of competitors.

3. The Economic Opportunity — What's Proven, Observed, and Potential

Revenue models in this space should be graded by evidence, not treated as equally validated.

Proven (an operator is currently running this model)

• Free-plus-paid newsletter — CourtWatch.news runs exactly this: a free weekly digest and a paid tier with deeper reporting.
• Grants and donations under a nonprofit, public-interest framing — the DC Witness model (operating as the nonprofit "American Witness"), funded primarily through foundation grants and contributions.
• Large-scale ad-supported media — Law&Crime proves that legal/true-crime content can be a major commercial media business, though at a very different scale and format (video-first, not case-file-first) than this blueprint.

Observed (a real product exists, but profitability isn't demonstrated)

• Structured data sharing with civic/research stakeholders — DC Witness maintains and shares homicide-tracking data, but this is documented as a public-service data product, not a proven profit center.
• Methodology/software licensing to local partners — Homicide Watch licensed its model to partner organizations in Chicago (with the Chicago Sun-Times), Trenton (with the Trentonian), and Boston (with Northeastern University). This validates that the model can be licensed — it does not by itself prove the licensing fees covered the cost of running it (see Section 6).

Potential (plausible, not yet evidenced in this space)

• B2B consulting for documentary/podcast researchers.
• Sponsorship of a specific beat by legal-adjacent businesses.
• Data licensing to legal-tech or insurance platforms as a standalone commercial product, distinct from the civic-data-sharing model above.

Treat the "Potential" tier as hypotheses to test with a real audience, not as line items in a business plan.

4. What the Website Actually Publishes

Four content types, not "articles":

1. Case files — one permanent, continuously updated page per case. The core unit of the site.
2. Timelines — a chronological record of filings, hearings, and developments, separated from the narrative write-up so it can be scanned in seconds.
3. Explainers — standalone pieces explaining a mechanism relevant to multiple cases (how bail works in this state, what a plea deal means, how restitution is calculated) — these rank independently in search and drive readers into case files.
4. Original analysis — pieces that step back from a single case to identify a pattern across several, produced under the originality safeguards in Section 8.

5. The Site & Data Architecture

Case tracking is not content architecture alone — it is data architecture with a content layer on top. Without a structured schema from day one, the "database" is really just a folder of editorial pages that happen to be about court cases.

Site Map

                    ┌─────────────────────────────┐
                    │         HOMEPAGE            │
                    │   (active cases + search)   │
                    └──────────────┬──────────────┘
                                   │
          ┌──────────────┬─────────┼─────────┬──────────────┐
          ▼              ▼         ▼         ▼              ▼
    ┌──────────┐  ┌────────────┐ ┌────────┐ ┌──────────┐ ┌────────────┐
    │  ACTIVE  │  │  RESOLVED  │ │EXPLAIN-│ │ PATTERNS │ │   CASE     │
    │  CASES   │  │   CASES    │ │  ERS   │ │ &ANALYSIS│ │  DATABASE  │
    │          │  │            │ │        │ │          │ │ (filterable│
    │ (live)   │  │ (archive,  │ │ (how   │ │(cross-   │ │  structured│
    │          │  │  by outcome)│ │ law    │ │ case     │ │   data)    │
    │          │  │            │ │ works) │ │ original │ │            │
    └────┬─────┘  └─────┬──────┘ └───┬────┘ └────┬─────┘ └─────┬──────┘
         │              │            │           │             │
         └──────────────┴────────────┴───────────┴─────────────┘
                                   │
                                   ▼
                             ┌────────────────┐
                             │   NEWSLETTER   │
                             │ (weekly digest)│
                             └────────────────┘

Underlying Data Model

Every case is a row in this schema before it's ever a page:

Field	Type	Purpose	Notes
case_id	UUID	Primary key
case_name	String	Display name
docket_number	String	Court identifier
jurisdiction	FK	Court/jurisdiction	Linked entity
court	FK	Court	Linked entity
case_type	Enum	Criminal/Civil/etc.
defendants	FK[]	Linked entities	Multiple, linked
victims	FK[]	Linked entities	Privacy-gated
attorneys	FK[]	Linked entities	Defense + prosecutor
judge	FK	Linked entity
charges	FK[]	Charge records	With legal status per charge
filing_date	Date
hearings	Log[]	Dated entries	Newest first
disposition	Enum	Verdict, plea, dismissal
sentence	String	If applicable
appeal_status	Enum	None/Pending/Resolved
linked_documents	FK[]	Primary sources
source_date	Date	When source was published
last_verified	Date	Drives stale-case metric
legal_status	Enum	charged/indicted/convicted/acquitted

Design note: defendants, victims, attorneys, and judge start as foreign keys even if the MVP renders them as flat fields — because converting them later from text to linked entities is the single most painful refactor in this schema's lifecycle. Plan for the linked model on day one, even if the UI doesn't surface it yet.

Case Page Template

Generated from that schema:

Case Name / Docket Number
   ├── Status (Active / Resolved) + Last Updated date
   ├── Summary (2–3 sentences, updated as the case evolves)
   ├── Timeline (dated entries, newest first)
   ├── The Money (if financial: what was taken, recovered, owed)
   ├── Key Documents (linked primary sources)
   ├── Related Cases / Patterns
   └── Update Log (transparent record of what changed and when)

6. The Operating Model

This is the section most "build a niche site" guides skip, and it's the one that decides whether the site survives. Case tracking is an ongoing operations commitment, not a one-time publishing decision. Every active case needs its docket checked, documents retrieved, updates verified, and pages revised — indefinitely, for as long as it's marked active.

The clearest real-world data point here is Homicide Watch D.C. At its peak it averaged roughly half a million pageviews a month, with strong return visitation — a genuinely engaged audience. And yet its founders described the cost of running it as, in effect, the cost of one full-time reporter dedicated to the courthouse beat. When the founders relocated and could not find a local partner willing to fund that ongoing role — despite years of trying and offering a licensing fee under $1,000/month — the original site closed. Strong audience numbers did not, by themselves, solve the operating-cost problem.

DC Witness's own FY2024 nonprofit filing tells a similar story from the inside: roughly $758,000 in revenue against about $790,000 in expenses — a modest deficit even for an established, grant-funded operation with a defined civic mission. Database journalism of this kind is not cheap to sustain, regardless of audience size.

Operating Metrics

Before writing a single case file, define:

Metric	Definition	Target	Warning Threshold
Cases per editor	Active cases one person can keep verified	15–25	>30
Update cadence (high-activity)	Check frequency for active cases	Daily	>48 hours
Update cadence (dormant)	Check frequency for quiet cases	Weekly	>14 days
Stale-case rate	% of "active" cases past their cadence	<5%	>10%
Source-failure rate	% of docket checks blocked/inaccessible	<15%	>25%
Escalation time	Time from flag to human review	<24 hours	>72 hours
Correction rate	Published corrections per 100 case files	<2	>5

Site health formula: Stale-case rate < 5% AND Correction rate < 2 = the site is doing what it promised. Stale-case rate > 10% = the site has operationally collapsed, even if traffic is high.

Beyond these metrics, three commitments must be defined in writing before the first case file publishes:

• The automation boundary — what the AI pipeline in Section 7 can safely do unsupervised (discovery, drafting, flagging) versus what always requires human sign-off (anything published, any legal-status claim, any newly named individual).
• Source-failure protocol — the fallback process when a docket or document source is inaccessible.
• Escalation path — who reviews a flagged legal or privacy risk before anything publishes.

Size the number of actively tracked cases to what this operating capacity can actually sustain — not to what would be editorially interesting to cover.

7. The Intelligence / Content Production System

This is an AI-assisted research and drafting workflow with mandatory human verification — not an autonomous AI newsroom. That distinction matters both operationally and for how this project should be presented to a technical audience: nine prompts move a case from discovery to publication, but a human editor owns every source judgment, every legal-status call, every pattern-validation decision, every publication decision, every sensitive-identification call, and every correction. The prompts produce drafts and flags; they do not produce final judgment.

Pipeline Overview

   ┌──────────────────────────────────────────────────────────────┐
   │  DISCOVERY         QUALIFICATION        RESEARCH             │
   │  ┌─────────┐       ┌─────────┐         ┌─────────┐          │
   │  │Prompt 01│──────▶│Prompt 02│────────▶│Prompt 03│          │
   │  │ Signal  │       │Qualify  │         │ Source  │          │
   │  │ Hunter  │       │ PASS/   │         │ Hunter  │          │
   │  │         │       │ FAIL    │         │ +Claim  │          │
   │  └─────────┘       └─────────┘         │ Ledger  │          │
   │                                        └────┬────┘          │
   │                                             │               │
   │  ANALYSIS              MAPPING              ▼               │
   │  ┌─────────┐          ┌─────────┐      ┌─────────┐         │
   │  │Prompt 04│◀─────────│Prompt 05│◀─────│         │         │
   │  │Analysis │          │ Entity  │      │         │         │
   │  │ w/ Safe-│          │  Map    │      │         │         │
   │  │ guards  │          │         │      │         │         │
   │  └────┬────┘          └─────────┘      └─────────┘         │
   │       │                                                     │
   │       ▼                                                     │
   │  ┌─────────┐      ┌─────────┐      ┌─────────┐             │
   │  │Prompt 06│─────▶│Prompt 07│─────▶│Prompt 08│             │
   │  │ Case    │      │Accuracy │      │ Update  │             │
   │  │ File    │      │+Privacy │      │ Check   │             │
   │  │ Builder │      │  GATE   │      │(requires│             │
   │  │         │      │         │      │ access) │             │
   │  └─────────┘      └────┬────┘      └────┬────┘             │
   │                        │                │                   │
   │                        ▼                ▼                   │
   │                   ┌─────────────────────────┐               │
   │                   │      Prompt 09          │               │
   │                   │  Update & Distribution  │               │
   │                   │  Engine                 │               │
   │                   └────────────┬────────────┘               │
   │                                │                            │
   └────────────────────────────────┼────────────────────────────┘
                                    ▼
                             ┌────────────────────┐
                             │  HUMAN EDITOR      │
                             │  Final sign-off on:│
                             │  • Legal status    │
                             │  • Named persons   │
                             │  • Pattern claims  │
                             │  • Publication     │
                             └────────────────────┘

Prompt 01 — Case Signal Hunter

You are a signal-monitoring researcher for a true-crime case-tracking site. Monitor for NEW SIGNALS in [JURISDICTION], including:

• New indictments, complaints, or charging documents
• Scheduled hearings, plea changes, or sentencing dates
• New filings or motions on cases already in our database
• Appeals filed on resolved cases
• Sealed-to-unsealed record changes
• Relevant DOJ, state AG, or local prosecutor announcements

Cross-reference every signal against our existing case database: if it belongs to a case we already track, flag it as an UPDATE (route to Prompt 08); if it's a new case, flag it as a NEW CANDIDATE (route to Prompt 02). For each signal, return: case name, docket/case number, jurisdiction, date, a two-sentence description, and a direct link or citation to the primary source. Flag clearly if only secondary coverage was found, with no primary document yet.

Prompt 02 — Signal Qualification

You are a qualification editor. Given this candidate: [OUTPUT OF PROMPT 01]

Run it through these gates — each is PASS/FAIL, not a score:

1. Primary documentation exists and is accessible?
2. Case is trackable via a real, checkable docket?
3. The alleged conduct has genuine public-interest value, independent of the people involved?
4. The case has realistic potential for follow-on developments worth tracking (not a one-and-done event)?
5. No unmanageable legal/ethical risk (minors, sealed records, active sexual-assault victim identification concerns) at this stage?
6. There is a plausible original-analysis angle, not just a rewrite of the charging document?

Any FAIL on gates 1, 2, or 5 is an automatic KILL regardless of the others. Return a verdict: PROCEED / HOLD (missing something specific, name it) / KILL (name the failed gate).

Prompt 03 — Research & Source Hunter

You are a primary-source researcher. For this case: [CASE NAME / DOCKET]

Build a source package: the original charging document/complaint, all subsequent filings and orders (chronological), the court calendar, any attributed statements from prosecutors/defense/the court, related civil, bankruptcy, or regulatory filings tied to the same parties, and local news coverage clearly separated from primary documents.

Then produce a CLAIM LEDGER — this is what makes citation checkable later, not just claimed:

Claim Ledger Format:

Claim ID	Claim	Source	Doc Date	Page/Para	Legal Status	Confidence
C-001	Defendant was charged with wire fraud	Indictment	2024-03-12	p.1, ¶3	Charged	Verified
C-002	Alleged scheme ran from 2019 to 2023	Indictment	2024-03-12	p.4, ¶12	Alleged	Verified
C-003	Defendant's attorney filed motion to dismiss	Court docket	2024-05-08	Entry 22	Filed	Verified
C-004	Prosecutors allege $2.3M was taken	DOJ press release	2024-03-13	¶2	Alleged	Attributed
C-005	Local outlet reported a plea deal is expected	Local news	2024-09-01	¶5	Unconfirmed	Secondary-only
C-006	Judge denied motion to dismiss	Court order	2024-07-15	p.2	Ruled	Verified

Fields: CLAIM ID | CLAIM | SOURCE | DOCUMENT DATE | PAGE/PARAGRAPH | LEGAL STATUS (charged/alleged/convicted/etc.) | CONFIDENCE (verified/attributed/secondary-only)

Flag explicitly: any fact you could NOT verify from a primary or clearly attributed source. Do not fill gaps with inference. Rows marked secondary-only cannot be used as fact in Prompt 06.

Prompt 04 — Original Analysis Engine (with originality safeguards)

You are an investigative analyst. Using this source package and claim ledger: [OUTPUT OF PROMPT 03]

Do not summarize the case. For each analytical claim you make, structure it as:

1. Observed pattern or relationship (stated precisely)
2. Evidence supporting it (cite specific CLAIM IDs from the ledger)
3. Alternative explanation that the evidence does not rule out
4. What cannot be established from the current source package
5. What additional data would be required to state this more strongly

You may NOT assert a pattern, scheme, or systemic conclusion unless the evidence in the claim ledger directly supports it. If the source package only supports "these cases share a superficial similarity," say that — do not upgrade it to "this reveals a pattern."

Prompt 05 — Entity & Content Map

You are an SEO / content architect. Given this case, its analysis, and claim ledger: [OUTPUTS OF PROMPTS 03 AND 04]

The permanent case page is an ENTITY page — it should answer the core, durable questions about this case for its entire lifecycle. Identify:

1. What belongs permanently on the case entity page (status, summary, timeline, money, documents)
2. What deserves a SEPARATE standalone piece with its own search intent (an explainer on a legal mechanism this case raises; a cross-case pattern piece)
3. 5–8 related search queries this case will generate over its life (arraignment, plea, trial date, sentencing, appeal)
4. Internal links to existing case files or explainers this case connects to

Return this as a content map — the outline for Prompt 06.

Prompt 06 — Case File Builder

You are a case-file writer. Using the source package, claim ledger, analysis, and content map: [OUTPUTS OF PROMPTS 03, 04, 05]

Write the case file with this structure: Summary (2–3 sentences) / Timeline (dated, newest-first) / The Mechanism / The Money or Harm / What Happens Next.

Rules:

• Every factual sentence must cite a CLAIM ID from the ledger — do not write a claim that isn't in the ledger. Claim IDs are internal provenance references; at publication, map each one to a reader-facing citation or source link appropriate to the publishing platform.
• Every person is described by their exact legal status at time of writing (charged/indicted/convicted/acquitted) — never imply guilt before conviction.
• No adjectives implying judgment ("shocking," "brazen," "evil") — the facts carry the weight.

Prompt 07 — Evidence, Accuracy & Privacy Gate

You are the final gate before publication. This is the single most important check in the pipeline for a site that names real people.

PART A — Accuracy:

1. Does every sentence trace to a specific claim ID? Flag any that don't.
2. Does the piece ever state guilt or an outcome before it occurred in the record? Flag any presumption of guilt.
3. Are all legal-status terms used precisely?
4. Are quotes attributed correctly and unaltered from source?

PART B — Privacy / Identification Gate (run on every case, no exceptions):

1. Is a minor named or identifiable? → HOLD for legal review.
2. Is a victim, witness, or uncharged relative named beyond what the primary record requires? → Flag for removal or anonymization.
3. Are home addresses, medical information, or sexual-assault victim identities present? → HOLD, remove/redact by default.
4. Does the case involve sealed or expunged records? → HOLD, do not publish sealed material.
5. Does the draft repeat an allegation that was later disproven or dropped without noting that status? → Flag for correction.

Return a pass/fail per section with the exact line and exact fix. Nothing publishes with an open flag from Part A or Part B.

Prompt 08 — Case Update Check

You are a case-monitoring assistant. This prompt is an INSTRUCTION that runs inside a docket-monitoring or web-research system with actual access to court sources — it is not itself a monitoring system, and cannot detect updates without that connection.

Case: [CASE NAME] | Last known status: [LAST TIMELINE ENTRY]

When run with source access, check for: new filings, hearing outcomes, continuances, plea changes, verdict/sentencing. If found: draft one new timeline entry (date + 1–2 sentences), note whether the summary/status needs to change, note whether "What Happens Next" needs revision. If nothing found, say so explicitly and give the next check date based on the court calendar.

Prompt 09 — Case Update & Distribution Engine

You are the distribution and knowledge-graph maintenance editor. Given an audit-passed update to a case: [OUTPUTS OF PROMPTS 07/08]

Produce:

1. The exact edit to the live case page (updated status, structured fields, new timeline entry)
2. A changelog entry (what changed, when, based on what source)
3. Which existing explainers or pattern-analysis pages are affected by this update and need their own review
4. A newsletter blurb (2–3 sentences) and a neutral, non-sensational social post — no adjectives implying guilt
5. 3–5 internal links to add or update
6. A judgment call, flagged for human review: does this update justify a new standalone article (e.g., a verdict, a major reversal), or does it stay contained to the case page's timeline?

8. The Original-Analysis Layer

The difference between a case-tracking site that becomes a real information asset and one that's a slower police blotter is this layer:

Raw filing / court record
          ↓
Verified claims (claim ledger, Prompt 03)
          ↓
Relationships between entities (Prompt 04, with originality safeguards)
          ↓
Mechanism — how it actually worked
          ↓
Pattern across multiple cases (human editorial review, not automated)
          ↓
A new information product: something a reader couldn't get from the court record alone

Cross-case pattern recognition — noticing that three cases share a method — is deliberately kept as periodic human editorial work reviewing the structured database, not something the per-case pipeline claims to do on its own. That's the part of the system that can't be templated, and it's exactly why it's valuable — and exactly where the originality safeguards in Prompt 04 matter most.

9. Real Website Examples

Homicide Watch D.C. is the strongest — and most honest — case study here, precisely because it proves both sides of this blueprint at once. It followed every homicide in D.C. from the killing through investigation and trial, combining courthouse reporting with structured, database-backed case information, and it licensed its methodology and software to partner organizations in three other cities. The detailed architecture in this blueprint (the specific schema, the claim ledger, the prompt pipeline) is a modern proposal built in that same spirit, not a literal description of how Homicide Watch's own system worked. What Homicide Watch does prove directly: it drew a genuinely engaged audience (roughly half a million pageviews a month at its peak), and it still closed — not for lack of audience, but because sustaining "the cost of one full-time reporter" indefinitely, without a committed local funding partner, proved unworkable once its founders relocated. Read this as validation of the format and a hard warning about the economics in Section 6, not as a cautionary tale to avoid mentioning.

DC Witness is the closest architectural match to this blueprint currently operating: AI-assisted processing of public court data, a structured case database, and reporters placed at the courthouse, tracking cases from act to resolution. Its FY2024 nonprofit financials (~$758K revenue against ~$790K expenses) show this is a real operating cost, not a side project — useful grounding for Section 6 rather than a reason for optimism alone.

Law&Crime, especially after its 2026 acquisition of Court TV, is a useful adjacent model, not a matching one: it proves legal/true-crime content can become a large, durable commercial media business at real scale. But it is a video-and-commentary media company, not a per-case-tracking product — its relevance here is as a reminder of the size of the audience interested in legal proceedings, not as a template for this specific architecture.

CourtWatch.news validates a narrower piece of the model: a strict primary-source-only policy (links to filings, minimal commentary) paired with a free/paid newsletter split, sustained by direct reporting costs. It's a legal-information model adjacent to true crime, not true-crime case tracking itself, but its funding structure is directly relevant to Section 3.

None of these fully combines readable narrative, structured filterable data, and systematic scheduled update-checking in one product — that combination, not an empty market, is the opening described in Section 2.

10. Monetization Architecture

Revenue layers here are not strictly sequential — they should be activated only when the audience and data justify them, not treated as a mandatory ladder every site must climb:

FREE CASE TRACKING (builds trust and search authority)
          ↓
AUDIENCE (readers bookmarking/returning to active cases)
          ↓
NEWSLETTER (the natural retention hook for a
             "following a case" audience — not optional, see below)
          ↓
       ┌───────────────┬──────────────────┬───────────────────┐
       ↓                ↓                  ↓                   ↓
PREMIUM TIER    DATA PRODUCTS      B2B / CONSULTING    SPONSORSHIP
(full archive,  (structured case   (documentary/podcast  (legal-adjacent
 ad-free)        outcome data,      researchers)          businesses)
                  licensed)

A retention layer is not optional; for this model, email is one of the strongest and simplest ways to deliver it. The entire value proposition of a case-tracking site is "we keep following this so you don't have to," and a newsletter or case-alert system turns that promise into a recurring product rather than a collection of pages. A consumer premium subscription, by contrast, may not fit every case category — test it rather than assume it.

11. Expansion Map

Structured data schema (Section 5), built from day one —
even while tracking only a handful of cases
          ↓
One case category, one jurisdiction, tracked properly
          ↓
Additional case categories (once operating capacity, Section 6,
allows it — not before)
          ↓
Cross-case pattern analysis (the site's original-reporting identity)
          ↓
Newsletter as primary retention channel
          ↓
Premium tier / data licensing / B2B — tested, not assumed
          ↓
Methodology licensing to new jurisdictions (the Homicide Watch model,
with its funding lesson from Section 6 applied)

The site should not grow into a database later — it should be a database from day one, even while small. What should grow slowly and deliberately is the number of actively tracked cases, gated by the operating capacity defined in Section 6. A wide site with stale case files fails the one promise that differentiates this model from ordinary news coverage.

Sources

• Nieman Lab — "Unable to find a local partner, the much-praised Homicide Watch D.C. is shutting down"
• Poynter — on Homicide Watch D.C.'s closure, audience, and operating cost
• PBS NewsHour — "Website That Kept Watch on D.C. Homicides Shuts Down" (confirms the Chicago/Trenton/Boston licensed sister sites)
• ProPublica Nonprofit Explorer — American Witness (DC Witness parent organization) FY2024 Form 990 financials
• D.C. Witness — official site
• The E.W. Scripps Company — press release on the sale of Court TV to Law&Crime
• Tubefilter — "Law&Crime just bought Court TV"
• CourtWatch.news — on its reporting costs and free/paid model
• UniCourt — court records and case-tracking platform (official site)

Written and edited by Hossam Seif, founder of Money Traces.