Do you need analytics for an AI-built side project?

An AI-built side project needs analytics from the first deploy, but it does not need a dashboard. The minimum is a page view script plus three or four custom events, written by the same coding agent that shipped the feature and read back by that agent when you ask whether anyone used it. I have shipped a lot of small projects this year, and the honest answer for most of them is that I never checked whether anyone turned up. Building got fast. Finding out what happened didn't.

Shipping got cheap, finding out what happened didn't

The cost of building a side project has collapsed and the cost of measuring one hasn't moved. In the 2025 Stack Overflow survey, 84% of respondents said they were using or planning to use AI tools in their development process. On the output side, Apple's App Store took roughly 560,000 new app submissions in the first half of 2026 and is on track to pass one million for the year, while downloads grew 2% over the same half, according to a July 2026 TweakTown report citing the New York Times. More things get built, roughly the same number of people show up to use them.

That gap is the whole argument. When building takes an evening, the scarce thing is no longer another feature, it's knowing whether the last one landed. The failure mode I keep seeing in my own projects is ship, post about it, forget. Three weeks later I can't tell whether the thing had four visitors or four hundred, so the decision to keep going gets made on how I feel that morning rather than on anything that happened.

What is the minimum analytics for a side project?

The minimum is page views with referrers, plus custom events for the signup step, the one action that defines a real user, and whatever you shipped most recently. That covers every question you will actually ask in the first few months:

You don't need funnels, session replay, retention cohorts or a dashboard on day one. You need those questions answerable in under a minute, because if it takes longer than that you'll stop asking. The three or four events matter more than the page views, since page views tell you about attention and events tell you about use, and a side project lives or dies on the second one.

Let the agent that built the feature instrument it

The coding agent that writes a feature is the right thing to add its tracking call, because it already knows what the feature is called, where the button lives, and what counts as success. Doing it later means a human remembering, and on a side project that human has a day job. With Lodd the call is one line, and the agent writes it as part of building the button, not as a separate task:

// the agent adds this while building the export button
exportButton.addEventListener("click", () => {
  window.ca.track("export_click", { format: "csv" });
});

For this to happen without you asking, the agent needs a standing instruction. A few lines in CLAUDE.md or AGENTS.md saying "when you build a new page or interactive element, add a tracking call for the meaningful action" is enough in my experience, along with a list of the events that already exist so it follows the naming. I wrote up the full snippet and what changed after I added it in how to make your AI agent analytics-aware. The short version is that an agent with the tracking API in context and a reason to use it will instrument as it goes, and an agent without either will ship five untracked components in two days, which is what mine did before.

Which analytics tools can a coding agent write tracking events for?

Any tool with a JavaScript event API: Plausible, Umami, Fathom, Pirsch, PostHog, OpenPanel and Lodd all accept a one-line custom event call that a coding agent can write. Writing is the easy half. The difference is whether the same agent can read the numbers back in the same session, and that needs an MCP server the tool either ships or doesn't.

The tool counts come from the individual comparison pages and the MCP comparison post, except OpenPanel, whose hosted MCP is newer and the closest to Lodd in shape. If you already run Plausible or Umami and like the dashboard, the community servers are fine for occasional questions. If the agent is the only thing that will ever look at the data, pick something where reading back is the primary interface rather than an add-on.

When you can skip it

Skip analytics when the project is for you alone, when you already know every user by name, or when you would not change anything based on the numbers. A CLI you built for yourself doesn't need page views. A tool three friends use doesn't need a signup event, you can ask them. And if you're honest that a project is a weekend experiment you'll abandon regardless, tracking it is busywork.

What you can also skip, for a long time, is paying. Side-project volume sits inside the free tier of most tools: Lodd is free up to 2,500 events a month, Umami's cloud tier is free to 100K events, PostHog's free tier is 1 million events. Plausible and Fathom have no free tier, which is a reasonable trade if you want their dashboards, and a poor one if nobody is going to open the dashboard.

Set it up in the same session you ship

The setup that actually sticks is the one that happens in the same coding session as the first deploy, because that's the only moment the project has your full attention. With Lodd the prompt is "Add lodd.dev analytics to this project." The agent writes the MCP config, authenticates with a code sent to your email, creates the site, embeds the script tag, and the next question you ask it, "which pages got traffic this week", comes back with real numbers. The Claude Code walkthrough shows each step; Cursor and Codex work the same way.

Two honest caveats. Lodd is newer and less battle-tested than Plausible or Fathom, and it has no dashboard at all, so if you want to glance at a chart on your phone it's the wrong pick. What it's built for is the case this post is about: a project that was built by an agent, will be maintained by an agent, and whose numbers will be read by the same agent when you ask. In that setup the dashboard was never going to be opened anyway.