For most client sites: HTML, CSS, and vanilla JavaScript — a deliberate choice, not a compromise. I deploy on Cloudflare (Pages or Workers), so the site sits on a global edge network with no cold starts. When a project needs React, a CMS, or something else, we scope it upfront.

Do you work with clients outside Italy?

Entirely remote, no geographic restrictions. If you can read this, we can work together.

How long does a project take?

A focused landing page can be production-ready in one to two weeks. A multi-page site with a CMS, bilingual content, or bespoke integrations typically takes three to five weeks. I'll give you a concrete estimate after our first conversation.

Do you offer maintenance after launch?

Yes, on request. I don't pitch retainers or lock you into contracts. If something needs updating, fixing, or expanding after launch, you reach out and we sort it.

Do you handle hosting and deployment?

On request. I know Cloudflare Pages well enough to set up the whole pipeline: DNS, deploy hooks, cache rules, the works. If you'd rather manage it yourself, I hand everything over in clean order.

Can you work on an existing site?

I prefer building from scratch: the result is faster, cleaner, and fully understood by both of us. That said, I can take on an existing site for well-scoped work: a performance pass, new sections, or targeted fixes.

How much does a website cost?

The right question is what scope the problem calls for. A focused landing page is very different from a multi-page site with a CMS, a contact form, and bilingual content. I give honest estimates after a first conversation, not before.

Can I update the site myself after launch?

On a static HTML site, you'd need to be comfortable editing code, or we plan a CMS/React layer from the start. If updating content without touching code is a real requirement, that changes the approach and we talk about it upfront.

What do you need from me to get started?

A clear sense of your goal, any existing brand assets (logo, colours, fonts), and the content you want on the site: text, images, anything you already have. That's enough for a first conversation.

What if I'm not happy with the result?

We work iteratively, so there's no big reveal at the end. You see work-in-progress at each stage and give feedback before we move forward. If something doesn't land right, we fix it before shipping.

Project-based or ongoing?

Both, depending on what makes sense. Some clients have a clear scope: build the site, hand it over, done. Others prefer to stay in touch for small updates over time. I don't push ongoing work where it doesn't add value.

All writingNote · Analytics

The analytics beacon the ad blocker ate

My /stats page showed zero visitors, including me, even with consent granted. The events were never leaving the browser, and the culprit was the one thing I had assumed was safe: the URL.

June 14, 2026AnalyticsCloudflare WorkersAd blockersDebugging

The symptom

I built my own analytics: opt-in, cookieless, first-party, no third-party scripts, the whole privacy-friendly checklist. It worked in testing. Then the public /stats page kept showing nothing. Not low numbers. Zero. Active visitors, page views, the live map: all empty, most of the time.

The strange part was that it was not always empty. Some visits registered. And when I opened the network tab on my own machine, with consent granted, the collect request was sitting there in red: net::ERR_BLOCKED_BY_CLIENT. The browser was refusing to send it, and the server never heard a thing.

Why it happens

ERR_BLOCKED_BY_CLIENT is not a server error or a CORS problem. It means something inside the browser cancelled the request before it left, and on a normal page that something is an ad or privacy blocker. uBlock Origin, EasyPrivacy, Brave shields, and most of their kin do not inspect what you send. They match the URL.

My endpoint was /api/metrics/collect. Two of those path segments, metrics and collect, are on every tracker blocklist, because Google Analytics has used /collect for years. It did not matter that my analytics were first-party and harmless: the path looked like a tracker, so it was treated like one. That also explains the 'most of the time'. Visitors without a blocker still counted, which is exactly enough data to make the dashboard look alive sometimes and dead the rest.

The fix

The blockers match path tokens, so the fix is to stop using tokens they match. I moved the endpoints to an opaque, first-party path with no tracker words in it, and kept the keepalive fetch that lets the beacon outlive the page. The Worker accepts the old path as an alias too, so redeploying does not drop events from clients still running the old bundle.

// Before: the beacon path tripped every ad-blocker list.
const ENDPOINT = '/api/metrics/collect' // "metrics" + "collect" are blocked

// After: an opaque, first-party path with no tracker tokens.
const ENDPOINT = '/api/wg/c'

fetch(ENDPOINT, { method: 'POST', body: payload, keepalive: true })

// The Worker keeps the old path as an alias, so the cutover drops no events:
if (path === '/api/wg/c' || path === '/api/metrics/collect') {
  return handleAnalyticsEvent(request, env)
}

After deploying, the request left the browser with my blocker still on, and /stats started counting me. This is the same trick Plausible and Umami document for self-hosting: serve the script and the endpoint from a path that does not advertise what it is.

The takeaway

Privacy-friendly is not the same as unblockable. Blockers do not read your privacy policy; they read your URLs. If you run first-party analytics and the numbers look impossibly low, open the network tab before you touch the database: a request shown as blocked, not failed, means the call never happened. And keep tracker words like metrics, collect, analytics, track, and event out of the path, because the path is the only thing the blocker sees.