I built a new app and I don't know how I feel about it

Published by<br>Phil Nash on<br>May 25, 2026

Subscribe to this blog

Much like almost every other developer on the planet, I have been trying to work out my relationship with coding agents. I have been using AI-assisted coding since the GitHub Copilot beta came out in 2021 (yes, that long ago) and have seen them evolve from being a fancy autocomplete to sidebar assistants to full-blown applications that don't even show you the code (unless you want to see it).

I've used almost all variations of coding assistants, but one thing I hadn't experimented with was building something new via prompts alone. I wanted to see what I could achieve with minimal touching of the code. So I powered up OpenAI's Codex and built a new app. I've launched it, I use it regularly, and I still don't know how I feel about it.

I built a time zone conversion app

The application I wanted to build was a time zone converter. I work on a globally distributed team and it's often very useful to know what time it is for everyone, especially if you want to send someone a message or organise a meeting. There are apps that do this already, like Savvy Time and World Time Buddy. They both work but have their issues; they are both full of adverts and seem to require page loads whenever you select a city to add to your time conversion, World Time Buddy doesn't work well on a mobile device, and Savvy Time is full of unnecessary information about time zones (presumably for SEO reasons).

I wanted to build something I could use and enjoy. Something that used modern web APIs to handle time zones, that prioritised performance, and that worked offline. Here is the first prompt I gave to Codex:

Create a plan to build a clean, simple, modern time zone comparison application, like the functionality in savvytime.com. It should be a modern HTML, CSS and JS front-end only application that can be made available offline using service workers. It should use the JavaScript Intl APIs to convert between time zones, but will need to map popular cities around the world to their time zone. By default the time you compare across different cities is the current time and date, but you should be able to choose the time and date. The state (cities, time and date selected) should be stored in the URL and loaded from the URL when the page is loaded. Use the Web Navigation API to control this.

It should work well on mobile as well as desktop and respect whether the user's system is using light or dark mode.

I started this one evening and over the next few hours, and then sporadically the next morning, Codex planned and I critiqued, it implemented and I reviewed, it wrote code and I tested the app. We had to work out fallbacks for APIs I thought were more available, design decisions for various elements and layouts, and ways to optimise the app. And after that there was an app that could be deployed. You can use the app here: https://time.philna.sh/.

This wasn't some sort of magical one-shot prompt and then I had an app. The first version that was built did satisfy the initial requirements, but that felt like the proof-of-concept that we could then build upon.

So how was the experience, the code, and the result?

The good

I was very impressed that in less than a day, and with a lot less attention than that, I was able to build an application that handles international time zones successfully with Codex. Codex did follow the directions I gave it, using Intl APIs for time zone handling, the Navigation API for handling URL changes, though we added a History API fallback. It also built this entirely as a vanilla JavaScript application with no framework, but a live-updating interface.

Codex also surprised me in a few ways. Its initial plan included making this a PWA that would work offline. It found an npm module (city-timezones) that had a list of cities mapped to their time zones that the Intl API would be able to use. It wrote end to end tests using Playwright.

The bad

It wasn't all good though. I certainly had to give Codex some extra direction to avoid potentially bad things.

It used the city-timezones module to generate a JSON data file that the front-end would load, but it included way too many fields from the original dataset. This app had no need for the latitude and longitude of the cities, nor their populations, but including that blew out the size of the data file. I got Codex to only include the properties we needed and the size of the JSON file dropped by nearly half.

I also added a feature to share the current URL, which contains all the cities you are comparing, optionally including the time and date that you are looking at, by copying it to the clipboard. Initially Codex chose to use the deprecated, non-standard document.execCommand('copy'); function. Had I not checked on the code for this feature, I wouldn't have noticed. I followed up with a prompt to use the standard Clipboard API and we got it...