Why local-first

SiteCMD is a desktop app. By default, your scans, findings, source code, and project history live on your machine. SiteCMD’s connected service stores operational data only for sites you explicitly connect; it is not a mirror of the local database.

This is a deliberate choice with real tradeoffs. Most “site health” tools are SaaS. Most of the obvious ones to compare us against are SaaS. We picked the harder path on purpose, and this page explains why.

If you want the operational specifics (which network requests we make, where data lives on disk, etc.), see Privacy & data.

The thinking

When you scan your website, what comes back is essentially a map of everything wrong with it. Misconfigured headers. Exposed secrets. Auth gaps. Database mistakes. Dependency CVEs. Performance problems. Accessibility failures.

That’s an extremely sensitive document. It’s the recipe for breaking your site.

The standard playbook for site-health tools is to store that recipe in their cloud. Your scans live in their dashboard. Your findings get indexed for search, fed into their analytics, sometimes used as case-study material. The data is technically yours, but it lives on someone else’s machine.

We didn’t want that to be the deal you get by default. So it isn’t: SiteCMD works completely without an account, and sending a site’s findings anywhere is something you turn on per site, for sites you want graded over time.

What local-first means in practice

• Your scan results stay on your machine by default. SiteCMD does not upload what your site is doing wrong unless you connect that site, which is a thing you set up deliberately and which sends findings and nothing that resolves to a file. See Connected sites.
• Your source code stays on your machine. The source audit reads files locally, analyzes them locally, and writes results to your local database. That one holds unconditionally: no path, content, or line number travels even from a connected site.
• Your project configuration stays on your machine. Project names, environment lists, integration credentials, history - all local. A connected site’s URL is registered with the service, because that is the thing being graded.
• Your agent fix briefs are built locally. When SiteCMD prepares the brief your coding agent picks up to fix an issue, it is constructed on your machine and served to your agent over MCP (which also runs on your machine). It doesn’t pass through us.

What this isn’t

Local-first isn’t the same as “offline” or “air-gapped” or “no network.” SiteCMD makes a few specific outbound requests on purpose:

• Live-site scans hit your URL (that’s the job).
• Integrations talk directly to the third-party APIs you connected (Google, GitHub, Cloudflare, etc.). They don’t route through us.
• Dependency lookups check public registries (npm, pypi, etc.) for known-bad versions. They send package names and versions, never your source.
• License validation confirms an existing subscription or connected-service/catalog credential is still valid. It does not control local feature depth.
• Update checks poll for new versions of the app.
• Optional telemetry only runs after you opt in from the desktop app. Usage analytics and crash/error reports are separate controls.
• A connected site sends that site’s findings to SiteCMD, once you connect it. It is the one request in this list that carries anything about what your site is doing wrong, and the one you have to turn on yourself.

SiteCMD does not upload source code, project paths, credentials, raw logs, or page content, and does not upload scan results from a site you have not connected.

For the specifics on each of those, see Privacy & data.

The tradeoffs

We picked local-first for the reasons above, but it costs us things real SaaS products get for free:

• No team sync without explicit sharing. If you and a coworker both run SiteCMD on the same project, your local databases don’t merge. You can share report exports, but there’s no “shared SiteCMD dashboard” model.
• No multi-device access by default. Your laptop has your scan history. Your desktop doesn’t. If you need both to know, you push findings into an external tracker.
• Harder support. We can’t see your data, so we can’t diagnose problems by looking at your account. Logs and reproductions are in your hands.
• No browser interface. Some workflows are easier from a browser. We don’t have one.
• Continuous operation is opt-in. The free local workbench stops doing work when the machine is unavailable. The connected service is the explicit hosted path for deploy watches, scheduled scans, shared baselines, and alerts while your laptop is closed.

These are real costs. We don’t paper over them. If you’d rather have a SaaS-flavored site-health tool, there are several good ones. SiteCMD is the one for people who specifically don’t want that.

Why a desktop app

The day-to-day work of looking at findings, triaging them, understanding what changed since yesterday, exploring correlations between a deploy and a regression, and verifying a fix needs a UI: filters, charts, comparisons, an event timeline, and a path from a finding to a fix.

That is why the current product is a desktop app. The local SQLite database is the source of truth for the app and its bundled MCP server, so your desktop workflow and AI editor see the same evidence without a hosted SiteCMD account.

The shape of the company we want to be

The business model has to match this. The complete local workbench is free. The commercial product is the connected service: hosted operation around production sites after deploys and between local sessions. We don’t sell access to your local data. We don’t sell ads against your projects. We don’t sell aggregated insights to your competitors.

Connected workflows stay bounded to each site you explicitly connect. They send the documented finding contract and operational identifiers needed for hosted execution; they do not quietly mirror your local database or source repository.

This is the explicit version of a promise. The implementation is in Privacy & data.