One developer, one product, three months: building with AI

KlipTrack consists of a native Android app, a server, a web workspace for the office and a company website. One person builds all four. The first line of code was written at the end of July; by mid-August, the office phones were already tracking working hours. That pace would have been unrealistic for one developer a few years ago. Today it is possible, with AI helping along the way.

This is what that looks like in practice: what got faster, where the tools made mistakes, and what I never hand over to them.

What got faster

Most of the time goes on work that is not difficult, just repetitive: carrying a new field from the database through the server to the interface, formatting an Excel export, adding another form, writing tests. AI can do that quickly and well when I tell it exactly what to do.

The server repository has 264 commits across 45 different days; the Android app has another 76. In early October, the automated test suite had 1,115 tests. I could not have written that many by hand on my own in the time available. With AI, I could. That speed depends on one thing: I can only make changes confidently when tests quickly tell me if something has broken.

Where it went wrong

AI does not work flawlessly, and I do not expect it to. I do expect mistakes not to keep recurring. That is why the project has a separate file documenting every serious one: what happened, what it affected and what would have caught it sooner. There are nineteen entries so far. A few lessons, in plain English:

• It suggested a setting when the app needed a mechanism. When a phone’s power management stopped the app, the first suggestion was to ask colleagues to change their phone settings. The right fix was a wake-up mechanism that works without anyone having to intervene. (Part three covers this.)
• It said a bug was fixed when only one path had been fixed. The same visit was closed by two different pieces of code, depending on whether we were looking at one day or a whole week. The daily view worked; the weekly view the office actually uses did not. There is now a test that specifically checks a multi-day query.
• A test passed for the wrong reason. It was green only because its sample data did not include the case that mattered. Real data exposed the bug. Now, where possible, I run important tests against the broken code too: if they still pass, the tests are not doing their job.
• It claimed something could not be checked without checking. It said there was no Android build tool on the machine, so two changes went out unverified. It turned out there was one; the build took 26 seconds.

AI mistakes are not different from human mistakes because they are a different kind. They are different because they sound confident.

The end of the file also records what went well. Two serious bugs were caught before release because, while answering a question, the tool reread the work it had just done. That habit is worth more than any particular tool.

What I do not hand over

Speed only matters if the decisions are good. These stay with me:

• What the product should do. Whether an approved correction counts towards paid hours or is shown separately is a business decision. AI can write either version; I discuss the right one with the client.
• Access to live data. The server holds location data from employees at real companies. By default, project rules give me read-only access to the live database. I do not query raw coordinates, only counts, times and statuses, and nothing changes live data without a separate, specific request.
• Releasing to production. I release new versions myself, and restarting the server requires my password. That is deliberate.
• Anything that cannot afford to be wrong. If a report concerns people’s working hours, every line comes from fixed rules, not a language model’s judgement. (Part four explains why.)

The contract between the phone and the server

I introduced one safeguard specifically because development moves quickly. The format of the communication between the phone and the server is documented and protected by its own test suite. The server can keep evolving, but never in a way that breaks an older version of the app still running on a colleague’s phone. If someone does not update for a week, tracking still has to work.

What this means for a client

The developer is the same person who hears the request, so it does not sit in a queue between the request and the solution. With KlipTrack, that often meant something requested on Monday morning was already working that afternoon.

It also means speed does not come at the expense of care. AI takes typing off my plate, not responsibility. If I cannot explain what a change does, I do not release it, whoever wrote it.

If you want to review or launch an app built with AI tools, see my service for fixing and preparing AI-built applications.