My team works across three continents. Scheduling a call often meant opening several timezone tools, passing screenshots around, and asking people to check the calculation again. We could see what time it was in each city. Deciding when to meet still took a conversation.
That was the problem behind Zonelyte: a shared view of a team's working hours, with enough context to choose a meeting time together. The useful unit was the team, not the clock.
Start with a decision someone already makes
I had been sitting on the idea for months. It was the kind of small project that could easily remain a private repository forever. What changed was getting to a visual prototype quickly enough to use it while the problem was still fresh.
I described a timezone grid to Google AI Studio: multiple cities, working hours shown through colour, and a way to highlight overlapping slots. In the original build, the first version took about 45 minutes. It used React, TypeScript, and Tailwind, and it looked coherent enough that I kept opening it.
That last detail mattered more than the speed. A prototype can be technically impressive and still tell you very little about whether anyone needs it. This one helped me perform a task I already had. It gave me a reason to return.
Keep the shared data model small
I had been using Supabase as my default for new projects. For Zonelyte, I tried Firebase. The core operation was simple: load a workspace, read its locations, and show changes to everyone looking at it.
The original workspace model reflected that simplicity:
workspaces/{shortId}
locations: [...]
name: string
createdAt: timestampFirestore's real-time updates fitted that interaction. I did not need a complex reporting model to answer the first product question. I needed a small shared document and a responsive view of it.
This was a choice for this workload, not a general verdict on databases. A product centred on relational queries might lead me somewhere else. The lesson was to choose around the operation the product performs most often, rather than reuse a default without questioning it.
Add accounts where they create value
The first version had no authentication. A workspace could be shared through its URL without asking the team to create accounts. That made it easy to put the tool in front of colleagues.
Saved personal presets introduced a different need. A person's favourite cities should follow them between devices and be available from the browser extension. That was a reason to add sign-in, without turning it into a requirement for the basic shared view.
AI Studio generated the initial Google sign-in integration. I still had to handle the surrounding details: script-loading order, the credential exchange with Firebase, and popup behaviour. These were small pieces of the interface, but they determined whether the experience actually worked.
Generating the outline was fast. Debugging those boundaries was where I learned the system. I would not describe the generated version as finished simply because the happy path looked convincing.
Put it in front of colleagues early
When I shared a link with the team, people added their cities and responded with concrete requests. Could they drag across a range of times? Could they share the workspace without making everyone register? Could the colours be easier to distinguish in dark mode?
Those requests were more useful than a speculative roadmap. They came from someone trying to make an actual meeting happen.
The feedback shaped proposal slots, reinforced the no-account sharing flow, and led to another pass on the palette. It also exposed a mistake in my process: I had waited weeks to share something that could have produced useful feedback much earlier.
Change tools when the work changes
As the codebase grew, I moved more of the work into Claude Code. The task was no longer simply to sketch a grid. It involved understanding existing components, changing several files together, and reasoning about state across the application.
AI Studio helped me explore the interface and reach a useful first version. Working inside the repository gave me a better place to handle refactoring, real-time synchronisation, the extension, and shared-workspace URLs.
I found the combination more useful than expecting one workflow to cover every stage. The question was what context the next change required, and which environment made that context available.
A prototype is the beginning of the work
By the time I wrote the original post, the product included shared workspaces, meeting proposals, calendar export, a Chrome extension, and a dark theme. The stack was React, TypeScript, Vite, Tailwind, and Firebase.
The first convincing prototype took less than an hour. Turning it into a product took months of evening work. Both statements are important. AI shortened the distance to something tangible; it did not remove the need to understand the system or observe people using it.
If I started again, I would show the first usable version to colleagues sooner, keep the initial data model small, and choose each AI workflow around the stage of work. I would also be more precise about what “built” means. A generated screen, a working demo, and a tool someone depends on are different milestones.
Explore Zonelyte, or browse more of my engineering projects.