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

From vanilla to React, and what it actually cost

I moved this site from hand-rolled HTML, CSS, and JavaScript to a React 19 SPA. It got heavier, not lighter. Here's why that was still the right call.

June 13, 2026React 19ViteArchitectureMigration

Why move at all

The old site was hand-rolled HTML, CSS, and JavaScript. It was fast and I was proud of it. But it had a structural problem: adding a page meant editing a build script, the shared global CSS, the navigation in every file, and the i18n dictionary, all by hand. Every new page made the next one a little more expensive.

That's the quiet trap of a no-framework site. The first ten pages are cheap. The eleventh is where you start paying interest on every shortcut you took. I wasn't fighting a performance problem. I was fighting a maintenance one.

What changed

The migration was to Vite and React 19, with react-router-dom for routing. The single biggest change wasn't at runtime. It was that a page became a file again.

// Before: every page was its own HTML file, and "adding a page"
// meant editing the build script, the shared CSS, and the nav by hand.

// After: a page is one lazy-loaded file. The router does the rest.
const NowPage = lazy(() => import('./pages/NowPage'))

<Route path="/now" element={<NowPage />} />
<Route path="/it/now" element={<NowPage />} />

Lazy-loading each route means the browser only downloads the code for the page you're on. The shared shell, the i18n bundle, and the heavy bits (the Leaflet map on /stats) are separate chunks. Adding this writing section was creating two files and four route lines: no build-script edit, no global-CSS surgery.

What it cost

Here is the honest part: the site got heavier. The vanilla version shipped almost no JavaScript. The React SPA ships an entry bundle around 128KB gzipped before it has rendered anything interesting. There's no spinning that as a win on raw bytes.

What those bytes buy: everything is first-party and self-hosted, there are zero third-party requests, the heavy code is split per route, and the whole thing caches immutably after the first visit. The first paint is slower than vanilla; every navigation after it is instant. For a portfolio people browse rather than bounce off, that's worth it. But it is a trade, not a free lunch.

What I kept

Most of the design system came across untouched, because it never lived in JavaScript. The CSS custom properties, the theme tokens, the flat i18n keys, the pre-paint script that prevents a flash of the wrong theme: all of it was already framework-agnostic. The migration was about how pages are assembled, not how they look. That's the payoff of keeping a design system in CSS rather than in components: you can swap the framework underneath it.

What I'd do differently

I'd move sooner. I treated the framework migration as a big, scary rewrite and put it off, when the design system was portable the whole time and the genuinely risky part was small. The lesson I keep relearning: the source-to-build separation I bolted onto the vanilla site was a workaround for a missing build step. The real fix was the build step itself.