# Develop
Source: https://docs.privacytracker.privacykey.org/develop/overview

Build privacytracker from source, understand the architecture, and contribute changes back.

This section is for people who want to **build, modify, or contribute to** privacytracker — not for people who just want to run it.

If you're looking to install and use privacytracker, the [Self-Host](https://docs.privacytracker.privacykey.org/quickstart) tab is what you want.

## Who this section is for

**You want to build from source**

Maybe to run on Windows or Linux desktop (where prebuilt binaries aren't published yet), or to try a change before opening a PR.

**You want to contribute**

Bug fixes, new privacy-label parsers, additional locales, or new dashboard widgets.

**You're integrating with the API**

Building tools on top of privacytracker's `app/api/**` routes — e.g. piping snapshots into your own data pipeline.

**You want to understand internals**

The data flow, the three crash-safe runners, the focus-driven feature-flag system, or the translations workflow.

## Where to start

**Step 1: Build from source**

Clone the repo, install Node 24, and run `npm run dev`. Full walkthrough in [Build from source](https://docs.privacytracker.privacykey.org/develop/build-from-source).

**Step 2: Read the architecture overview**

[Architecture](https://docs.privacytracker.privacykey.org/develop/architecture) covers the codebase shape, the seven-step scrape→snapshot→diff→notify loop, the SQLite model, and the three crash-safe bulk runners.

**Step 3: Understand the feature-flag system**

Every user-facing surface is gated by a focus model: audience × goals × accessibility. [Feature flags](https://docs.privacytracker.privacykey.org/develop/feature-flags) explains the resolver, the storage model, and how to add a new flag.

**Step 4: Contribute translations**

`locales/en.json` is the source of truth. Other locales round-trip through Crowdin. See [Translations](https://docs.privacytracker.privacykey.org/develop/translations) for the workflow.

## Tooling

Day-to-day commands you'll actually use:

```bash
npm install            # requires Node 24 LTS
npm run dev            # http://localhost:3000
npm run lint           # Ultracite (Biome) — lint + format check
npm run typecheck      # TypeScript without emitting files
npm test               # focused node:test suite
npm run lint:i18n      # check locales/*.json key parity against en.json
npm run build          # production build
```

## Repo layout at a glance

```
privacytracker/
├── app/                Next.js App Router pages + API routes
├── lib/                server-side logic — most of the product lives here
├── src-tauri/          Rust desktop shell + sidecar lifecycle
├── scripts/            out-of-band scripts (ios-app-import companion, screenshots, standalone staging)
├── deploy/             reference reverse-proxy stacks (caddy/, traefik/)
├── tests/              node:test suites + Playwright specs
├── data/privacy.db     SQLite database (gitignored)
├── locales/            i18n bundles (en.json is the source of truth)
├── AGENTS.md           coding-agent instructions for Codex
└── CLAUDE.md           coding-agent instructions for Claude Code
```

Anything not here — release pipeline, code signing, the GitHub Actions that publish notarized builds — is intentionally out of scope for this docs site. The point of the public docs is to help users self-host and contributors get productive; release engineering is internal.

## Reporting issues

[github.com/privacykey/privacytracker/issues](https://github.com/privacykey/privacytracker/issues). Bug reports use the `bug_report.yml` template; security reports follow [SECURITY.md](https://github.com/privacykey/privacytracker/blob/main/.github/SECURITY.md).