I wanted audio versions of my blog posts. Just a play button for an article, with speech that sounded natural enough that people would actually use it. I could have solved that by paying for a hosted text-to-speech (TTS) service and moving on, but I wanted more control than that.

## Hosted TTS was the baseline, not the answer

I tried [ElevenLabs](https://elevenlabs.io/) first, and to be fair, it worked. The output quality was good, setup was easy, and it immediately proved that article audio was worth doing.

It still felt wrong for what I actually needed.

I did not want a big platform with a long feature list, pricing I had to keep thinking about, and my content flowing through someone else's product just to narrate a few articles. My use case was much smaller and much more specific: take text I already own, turn it into audio, keep the workflow simple, and keep the whole thing under my control.

That pushed me toward open models. I wanted something I could inspect, adapt, and run locally. Once I found the [Kokoro ONNX model on Hugging Face](https://huggingface.co/onnx-community/Kokoro-82M-v1.0-ONNX), the project stopped looking like a vague idea and started looking like an engineering problem I actually wanted to solve.

## From Python proof of concept to LocalVoice Studio

I started with the smallest possible test: a Python script in the terminal. Paste in some text, run synthesis, listen back, repeat. That first proof of concept was rough, but the voice quality was good enough that I immediately stopped thinking in terms of "can this work?" and started thinking in terms of "how far can I push this in the browser?"

That turned into [LocalVoice Studio](https://localvoice-studio.netlify.app), a static frontend app built with Vue, TypeScript, ONNX Runtime Web, and `kokoro-js`. No backend. No cloud inference. No telemetry. Speech generation happens in the browser and, after the initial model download, the app is meant to keep working offline too. That distinction matters. "Local-first" is easy to say, but I wanted to be clear about what it means in practice. The model download is a one-time cost, but the app's behavior after that is what defines the experience.

At that point the goal changed a little. I was no longer building a thin article player. I was building a small studio for producing article audio. It was about being able to give a personal touch to the audio and play with the voice settings. I wanted to make it feel like a creative tool, not just a synthesis utility.

## The difference between a demo and a tool

The model itself was only part of the work. The harder part was making browser TTS feel stable enough that I would trust it for real writing.

Inference runs in a dedicated worker because I had no interest in freezing the UI every time the model initialized or generated audio. The app prefers WebGPU when the browser can support it, but it can retry on WASM if GPU startup fails. That fallback path was one of the most important decisions in the project. Browser AI is full of features that look impressive on one machine and fall apart on the next. If runtime selection is brittle, the app is brittle.

I also did not want voice settings to feel like blind guesses. So the app generates previews, keeps local history, stores presets in the browser, supports voice blending, and lets you control pronunciation more directly with inline markup for pauses, stress, and phoneme overrides. That is the part I enjoyed most as a web developer. Once the raw speech quality is good enough, the real product work shifts to feedback loops. Can I preview a change quickly? Can I recover a setting I liked? Can I export something useful without extra cleanup?
To me, delivering a good user experience, is more important than adding "AI-powered" in the landing page.

That is also why I kept the output practical. You can generate speech, play it back, download it as WAV, clear caches, and keep moving. It needed to feel like a local tool I could come back to, not a one-shot demo I would show once and forget.

## AI made it fast - guardrails made it shippable

This project was also an experiment in AI-assisted development. I used Codex in VS Code, Gemini through Antigravity, and the usual modern tooling around a Vue codebase. The speed is real. You can move from rough idea to working interface much faster than I could have a year ago.

The part people keep underselling is how quickly that speed turns into drift if you do not put boundaries around it.

I had to be explicit about the shape of the project: static frontend only, worker-driven inference, typed state, clear constraints around privacy, and no backend escape hatches. I also had to keep the boring guardrails in place from the start: linting, formatting, Vitest, Playwright, accessibility checks, and runtime recovery when WebGPU failed. That was the QA lead part of my brain taking over. I do not really care that an agent can scaffold ten components in a minute if the result becomes impossible to trust once real users touch it.

AI is great at accelerating implementation inside a box. It is much worse at deciding where the box should be, how strict it needs to stay, and what quality bar the project has to clear before it deserves to ship. That part is still on us.

## What I took away

I did not build this because I think every problem needs a local AI app. I built it because this one did. Article audio is a narrow problem, and a browser-first, open-source TTS tool turned out to be a much better fit for it than another subscription.

The bigger lesson for me is that local-first AI gets interesting when you stop treating the model as the product. The product is everything around it: fallback behavior, caching, previews, export, tests, and enough constraints that the code does not dissolve into vibes halfway through the build.

If you want to study or reuse the approach, the [repo is here](https://github.com/Archetipo95/localvoice-studio). If you are building something similar, I would start with the smallest proof of concept you can get running, then spend more time than you think on guardrails. The demo is the easy part. Making it hold up is the work.

A US-based client opened a ticket: the travel itinerary showed **February 26th** instead of **February 27th** for a Rome-to-Milan transfer. One day off. In travel, that's a stranded passenger.

I debugged the whole thing from VS Code using [Chrome DevTools MCP](https://github.com/ChromeDevTools/chrome-devtools-mcp), which lets an AI agent control Chrome's debugging tools (network inspection, console, DOM) through the [Model Context Protocol](https://modelcontextprotocol.io/). Instead of manually toggling Chrome's timezone settings and reloading four times, I had the agent run timezone simulations in the browser console, inspect the network payload, and verify the fix. One editor session, start to finish.

---

## The bug

The client in New York saw this:

| Field    | Expected          | What they saw     |
| -------- | ----------------- | ----------------- |
| Pick up  | 27/02/2026, Rome  | 26/02/2026, Rome  |
| Drop off | 27/02/2026, Milan | 26/02/2026, Milan |

The dates were exactly one day off, both of them. Not random corruption, not a calculation error. A one-day shift that's consistent across fields smells like a timezone conversion that shouldn't be there. From my machine in Rome (UTC+1), everything looked correct, which made it worse. I needed to see what the client was actually seeing.

---

## Reproducing the bug with MCP

The traditional approach to timezone bugs: open Chrome DevTools, change the timezone in sensor overrides, reload, inspect. Repeat for each timezone. Slow, tedious, easy to mess up.

Instead, I had the MCP agent run a simulation directly in the browser console, testing how the frontend's date code behaves across four timezones at once:

```typescript
const serverDate = "2026-02-27"
const parsed = new Date(serverDate)

const timezones = ["Europe/Rome", "America/New_York", "America/Los_Angeles", "Asia/Tokyo"]

const results = {}
timezones.forEach((tz) => {
  results[tz] = parsed.toLocaleDateString("it-IT", { timeZone: tz })
})
```

| Timezone            | Displayed date | Correct? |
| ------------------- | -------------- | -------- |
| Europe/Rome         | 27/02/2026     | ✓        |
| America/New_York    | 26/02/2026     | ✗        |
| America/Los_Angeles | 26/02/2026     | ✗        |
| Asia/Tokyo          | 27/02/2026     | ✓        |

Bug confirmed. Any negative UTC offset shows the previous day.

## Tracing the data

MCP's network inspection showed what the server was sending:

```json
{
  "start_date": "2026-02-27",
  "end_date": "2026-02-27",
  "origin": { "name": "Rome" },
  "destination": { "name": "Milan" }
}
```

Plain `YYYY-MM-DD` strings. No time component, no timezone offset. Just a calendar date. The server was fine.

## The root cause

The Vue component that renders the date:

```typescript
const formattedPickupDateTime = computed(() => {
  const date = new Date(props.pickupDate)
  const formatted = date.toLocaleDateString("it-IT")
  return { date: formatted, time }
})
```

There it is. `new Date('2026-02-27')` parses the string as UTC midnight. Then `toLocaleDateString` converts to the user's local timezone.

In Rome (UTC+1): midnight UTC becomes 1:00 AM on the 27th. Correct.
In New York (UTC-5): midnight UTC becomes 7:00 PM on the 26th. Wrong.

The `Date` constructor was the trap. The string `"2026-02-27"` looks harmless, but once it enters JavaScript's Date system, it picks up timezone semantics nobody intended.

---

## The fix

The server sends calendar dates: a day on a calendar, not a moment in time. The fix was to stop treating them as moments:

```typescript
function dateToString(dateString: string): string {
  if (!dateString) return ""
  const cleanDateString = dateString.substring(0, 10)
  const [year, month, day] = cleanDateString.split("-")
  return `${day}/${month}/${year}`
}
```

Updated component:

```typescript
const formattedPickupDateTime = computed(() => {
  const date = dateToString(props.pickupDate)
  return { date, time }
})
```

No `new Date()`. The string `"2026-02-27"` gets split on hyphens and rearranged into `"27/02/2026"`. Same output in Tokyo, Rome, and New York.

After deploying, I used MCP again: the same simulation that found the bug now confirmed the fix. Four timezones, all showing 27/02/2026, no Chrome settings changed.

---

## Locking it down with tests

If anyone refactors `dateToString` to use `Date` objects later, these tests should catch it:

```typescript
import { describe, it, expect } from "vitest"
import dateToString from "@/utils/dateToString"

describe("dateToString", () => {
  it("reformats YYYY-MM-DD to DD/MM/YYYY", () => {
    expect(dateToString("2026-02-27")).toBe("27/02/2026")
  })

  it("returns empty string for falsy input", () => {
    expect(dateToString("")).toBe("")
  })

  it("handles date strings with time components", () => {
    expect(dateToString("2026-02-27T23:00:00Z")).toBe("27/02/2026")
    expect(dateToString("2026-02-27T00:00:00+01:00")).toBe("27/02/2026")
  })
})
```

The tests above verify correctness, but they won't catch a timezone regression. If someone refactors `dateToString` to use `new Date()`, the tests still pass on any machine where the local timezone has a positive UTC offset. They'd only fail in CI if the runner happens to be in a negative-offset timezone.

To actually catch that, the standard way in a Node.js environment like [Vitest](https://vitest.dev/api/vi.html#vi-setsystemtime) is to set the `TZ` environment variable. In modern Node.js versions, you can even switch timezones dynamically between tests:

```typescript
import { it, expect } from "vitest"

it.each([
  { tz: "America/New_York", expected: "26/02/2026" },
  { tz: "Europe/Rome", expected: "27/02/2026" },
  { tz: "Asia/Tokyo", expected: "27/02/2026" },
] as const)("produces $expected when TZ=$tz", ({ tz, expected }) => {
  process.env.TZ = tz
  expect(dateToString("2026-02-27")).toBe(expected)
})
```

_(Note: While Node.js 22+ handles `process.env.TZ` changes dynamically, in older versions the timezone was cached after the first `Date` was created. If you are on an older stack, you might need to run separate test processes or set the timezone at the very top of the file.)_

---

## Why this catches everyone

`new Date('2026-02-27')` parses as UTC midnight: `2026-02-27T00:00:00.000Z`. This is per [ECMA-262 §21.4.3.2](https://tc39.es/ecma262/#sec-date): date-only strings are interpreted as UTC.

Meanwhile, `new Date(2026, 1, 27)` creates a date in the _local_ timezone. Two constructors, two different timezone behaviors. I've known this for years and still almost missed it.

The original code was written and tested in Rome. UTC midnight is 1:00 AM in Rome, still on the 27th, so the bug was invisible during development. It only surfaces in negative-UTC timezones, where midnight UTC falls on the previous calendar day. I develop in Rome. Of course I didn't see it.

---

## What I took away

**If you're displaying a calendar date, don't put it through `Date`.** Split the string, rearrange, render. But document why. The next developer will look at `dateToString` and think "why didn't they just use `toLocaleDateString`?" The comment is part of the answer. The `timezone-mock` tests are the rest: they show exactly what breaks if someone swaps in `new Date()`.

**Timezone bugs are invisible from positive-UTC locations.** UTC midnight is still the right calendar day in Western Europe and East Asia. The bug only shows up in the Americas.

**Chrome DevTools MCP collapses the debugging loop.** The traditional timezone-toggle routine takes minutes of clicking around per cycle. The agent tested four timezones in one console evaluation, then the same simulation verified the fix. The debugging context stayed in one place instead of splitting across browser tabs, terminals, and my head.

---

_Debugged with [Chrome DevTools MCP](https://github.com/ChromeDevTools/chrome-devtools-mcp), Vue 3 and Nuxt 4, and a healthy suspicion of `new Date()`._