Why Lintry does not use analytics — and why you might not need them either

No Google Analytics. No Plausible. No Mixpanel. No Hotjar, no Heap, no PostHog. When we launched Lintry in May 2026, we shipped with zero behavioral tracking on the marketing site and the application. This was a deliberate choice, and we are not pretending it was a hard one. Here is the reasoning, the tradeoffs we accepted, and what we actually use to understand whether the product is working.

The default everyone reaches for

When you build a SaaS, there is a checklist. Domain. Hosting. Stripe. Email. Analytics. Adding Google Analytics or Plausible is something developers do on day one without thinking about it. You drop in a script tag, you start collecting pageviews, and you tell yourself you will look at the data later. Usually you never do.

We skipped that step. Not because tracking is evil — it is not — but because the actual return on investment for analytics at the scale of a new SaaS launch is almost zero, and the cost in trust, compliance, and complexity is real.

The honest case for analytics

Analytics are useful for:

• Funnel analysis at scale — when you have 10,000+ visitors a month and you need to find where they drop off
• A/B testing — when you have enough traffic to get statistically significant results in a reasonable timeframe
• Channel attribution — when you spend money on paid acquisition and need to know which channel converts
• Cohort analysis — when you have repeat behavior to study over months

All of these matter. None of them apply at the launch of a SaaS with zero customers.

What we would learn from analytics on day one

Imagine we had Plausible installed on lintry.io. On launch day, we would see:

• X pageviews
• Y bounce rate
• Z average session duration
• Top pages, top referrers, top countries

Genuinely useful question: what do we do with this information at day one?

We do not have enough traffic for statistical significance. We do not have a paid acquisition channel to attribute. We do not have a funnel deep enough to optimize. The data exists but it does not drive a decision. It would be a vanity dashboard.

Meanwhile, the actual leading indicators that matter at launch — Did anyone sign up? Did they try a scan? Did they upgrade? — are already in our database. We do not need a tracker for that. We need a SQL query.

What you actually pay for analytics

Free analytics are not free. The price is paid in:

Page weight

Google Analytics's gtag.js script weighs about 50KB minified. Plausible's is smaller at around 1KB. Either way, that is real network traffic on every page load — and modern web performance is brutal. Lighthouse penalizes you for third-party scripts. Core Web Vitals get worse. SEO suffers.

Privacy compliance overhead

Once you install behavioral tracking, you need a cookie consent banner under GDPR. You need to disclose every third-party processor in your privacy policy. You need to handle data subject access requests. You need to think about international data transfers. Plausible avoids most of this by not using cookies — but the moment you reach for Mixpanel or PostHog with user identification, the compliance burden snowballs.

Trust signals

Sophisticated users open DevTools. They see the third-party scripts. They form opinions about your product based on what those scripts do. A developer-tool company shipping with Facebook Pixel installed loses credibility instantly. The trust cost is invisible until it is not.

The "we'll look at it later" lie

The honest truth about analytics at most early-stage startups: nobody looks at the data. The dashboard exists. People glance at it during board meetings. Nobody actually builds a decision from the bounce rate of /pricing. You collected the data because everybody else does, not because it changed what you shipped.

What we use instead

The honest version of "we have no tracking" is "we collect the minimum we need to operate the product, and we do not pretend to do otherwise." Specifically:

That is it. No third-party scripts. No cross-site tracking. No fingerprinting. No behavioral profile being built against any visitor's session. Every piece of data on the list has a clear job and a defined retention policy. None of it leaves our infrastructure.

The Google Search Console exception

Worth being explicit about this. We use Google Search Console to understand SEO performance — which queries surface our pages, what the click-through rate looks like, where we rank.

GSC is not a tracking script on our site. Google already tracks searches on google.com regardless of whether we are on Search Console. GSC just gives us access to data Google was going to collect anyway. We are not adding any tracking to our visitors — we are reading reports about queries that hit Google, not us.

What we lose

Fair to be specific about the tradeoffs. Without analytics, we do not know:

• Where on a page visitors stop scrolling
• Which CTA buttons get clicked vs ignored
• How long visitors stay on each page
• What the actual conversion funnel from landing → pricing → signup looks like in aggregate
• Heatmaps, session replays, scroll depth

We accept this. At our scale, those signals are noise — too few data points to be statistically meaningful, and the time spent staring at dashboards is time not spent talking to customers directly.

What we have instead: direct customer conversations. The first 100 users get an email asking what they liked and what was confusing. The next 100 get a follow-up survey. We will know exactly which CTA got missed because someone will tell us. That is a higher-signal data source than session replay.

When we will add analytics

We are not anti-analytics forever. There is a real moment when adding tracking makes sense:

• When we have a paid acquisition channel and need attribution to measure ROI
• When traffic is high enough for A/B tests to reach significance in under two weeks
• When the funnel is complex enough that direct conversations cannot reveal where drop-off happens

Probably 6-12 months from launch. When we add it, we will likely pick Plausible or Cloudflare Web Analytics — both privacy-respecting, cookieless, GDPR-compliant by default, and roughly 1KB of script weight. We will not reach for Google Analytics. We will not reach for any tool that builds behavioral profiles across sessions.

And we will update the privacy policy and disclose it the same day we add it.

Should you skip analytics too?

Probably yes, if any of the following apply:

• You are under 10,000 monthly visitors
• You have direct relationships with most of your users
• You are not running paid acquisition
• You have a privacy-first positioning to maintain
• You have not articulated a specific decision you would make differently if you had the data

Probably no, if:

• You run paid ads and need attribution
• Your funnel is multi-step and not directly observable
• You have a team that uses the data for real decisions, not slide decks

The honest test: name one decision you made last quarter based on your analytics data. Not "we noticed bounce rate went up" — an actual product or marketing decision driven by the data. If you cannot name one, your analytics are vanity, not signal.

"The data exists but it does not drive a decision. It would be a vanity dashboard."

The real point

We did not skip analytics to be edgy or contrarian. We skipped them because for a SaaS at our stage, the cost is real and the value is mostly imagined. We will add tracking when it actually helps us make decisions — not before, and not because the checklist said so.

In the meantime, we built a privacy posture that is consistent with what we tell users on our marketing site. No tracking cookies. No third-party trackers. No surveillance. The privacy commitments in the policy are real, because there is nothing to walk back.

If you ship products, audit your own analytics stack the same way we audited our own homepage. Ask which tool actually drives a decision and which one is just there because everyone has it. Then decide what to keep.