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 · CSS

The backdrop-filter that ate my fixed nav

A blurred sticky header quietly trapped a position: fixed overlay inside it. Here's why, and the one-line mental model that explains it.

May 16, 2026CSSbackdrop-filterDebugging

The symptom

I had a sticky site header with a blurred background and a full-screen mobile nav panel set to position: fixed; inset: 0. On desktop everything was fine. On mobile the panel refused to cover the viewport: it was clipped to the header's box, sitting in a thin strip at the top instead of filling the screen.

No overflow: hidden anywhere. No transform on an ancestor. The markup was correct. The panel was a child of the header for accessibility reasons, and that turned out to be the entire problem.

Why it happens

position: fixed is positioned relative to the viewport, usually. The exception is when an ancestor establishes a containing block. transform, filter, perspective, will-change, and contain all do this. So does backdrop-filter.

The moment you put backdrop-filter on the header, the header becomes the containing block for every fixed descendant. inset: 0 stops meaning the viewport and starts meaning the header's padding box.

.site-header {
  position: sticky;
  top: 0;
  backdrop-filter: blur(10px); /* ← creates a containing block */
}

/* The panel wants to cover the viewport... */
.nav-panel {
  position: fixed;
  inset: 0; /* ...but inset is now relative to .site-header, not the viewport */
}

The fix

Keep the blur off the ancestor chain of the fixed element. Move backdrop-filter onto an absolutely positioned ::before pseudo-element on the header. The pseudo-element blurs what's behind the header, but it is not an ancestor of the nav panel, so it never establishes a containing block for it.

/* Keep the blur, but on a pseudo-element that isn't an ancestor
   of the fixed panel. The header no longer establishes the
   containing block, so position: fixed snaps back to the viewport. */
.site-header {
  position: sticky;
  top: 0;
}

.site-header::before {
  content: "";
  position: absolute;
  inset: 0;
  z-index: -1;
  backdrop-filter: blur(10px);
}

The header looks identical. The panel goes back to covering the viewport. Same visual result, no trap.

The takeaway

Whenever a position: fixed element is clipped to the wrong box, stop inspecting the element and start walking up the tree for the containing-block triggers: transform, filter, backdrop-filter, perspective, will-change, contain. One of them is on an ancestor. The element is behaving exactly as specified. The surprise is that a purely visual property carries a layout side effect.