I built a time tracker without touching the code: declarative architecture programming with Claude

I ran an experiment: build a complete product without writing or editing a single line of code myself. Not a script, not a prototype - a web app with a backend, a database, a phone layout, an installable PWA, a Chrome extension and a landing page. In my spare time after my regular job, over a few days.

Before the "even a time tracker needs vibe coding" comments: yes, I know, a time tracker is not a spaceship. I am a backend developer, and everything under the hood (the API, the database, the modules) I could have written by hand, without any model. It was planned and designed by me, and the model only filled in the implementation. The point is not that the app is hard. The point is that a complete, working product can be made without ever looking at the code.

The frontend is a different story. I am not a frontend developer, so there I worked at the level of intuition and engineering understanding: how it should feel, how it should behave, what goes where. That is a level above the code. So here is the question I want to put to you up front: if an app is built this way, is it still "yours"? Would you take a good app made fast by a model over a good, slower and smaller one written by hand? I have my own answer below, and I would like to hear yours.

The result is Overdraft, a personal time tracker. It has no users yet. I just released it, and I never planned to advertise it. I made it for myself and for my son. This post is about how it was made, and what I think that says about where programming is going.

The idea

I wanted something simple: press play on a task, and later see where the time actually went. Not a timesheet, not a team tool. A mirror for personal time, and maybe a way to regulate "wasting" it.

A few rules came from that, and they are all mine:

• One running task at a time. Start another one and the current one stops by itself.
• A daily cap per task. Two hours of games is fine; the counter turns red when you cross it.
• Four fixed lists: Backlog, Progress, Today, Tomorrow. No custom lists and no long-term projects. Backlog holds only what is really coming up, and Today and Tomorrow are a tiny one-day planner.
• Tracked time cannot be edited, so the numbers stay honest.
• Sleep counts too. You have 24 hours a day, and sleep is part of the budget.

How it was actually built

The idea, the product decisions and the architecture were mine. The code was written entirely by Claude, through Claude Code. I did not open an editor to fix "just one line". If something was wrong, I said what was wrong, and the model changed it.

What that looked like in practice:

1. I described the module boundaries first. Backend: Java 21, Spring Boot, PostgreSQL, Flyway, split into auth, board and progress modules with explicit contracts between them. Frontend: Vite, React, TypeScript, one flat structure. Each module has a short CLAUDE.md that states what it owns and what it must not know about.
2. I kept a set of written standards that the model loads in every session: language rules, commit format, how secrets are handled, how Docker is laid out, how a plan must mark decisions that the standards do not cover. The model does not have to guess my taste; it reads it.
3. I worked in small steps and kept decisions in writing. Open questions, known bugs and future ideas went into plain markdown files in the repo, not into my head.
4. I reviewed behavior, not code. I used the app, looked at the screen, said "this feels wrong", and described what it should do instead.

The repository today has about 25,000 lines of Java, TypeScript, CSS and SQL, 23 database migrations and 184 commits made over six days. I wrote none of those lines.

What came out

• Web app with the four lists, drag and drop, a task page with a time chart, groups with colors, optional daily caps.
• Stats: week, month, year and all time, as bars, lines or an activity calendar, with group filters, a CSV export and a side-by-side comparison of any two days.

• A day strip under the board: a timeline of sessions by hour, or a "breakdown" of the whole day as one bar (missed time, sleep, groups, what is left).
• Phone version: one list per screen, swipes between lists, a bar with the running task on every page, swipe to stop it.
• PWA: installable, works offline for reading, push notifications when a cap is reached or a timer was left running.
• Chrome extension: start and stop tasks from the toolbar, with the running time on the icon.

• Three interface languages (English, Russian, Ukrainian), encrypted task text in the database, Google sign-in, one-command deploy to a small VPS.
• A landing page, with screenshots and videos recorded by scripts on demo data, also produced with the model.

Declarative programming is old news. This feels different

We have been writing declaratively for a long time: you say what you want (SQL, HTML, config) and the engine decides how. What I did here is one level up. I did not describe the code. I described the architecture: what the parts are, what each one owns, where the boundaries are, what is forbidden, and what the product must feel like. The implementation was left to the model.

Maybe it deserves a name like declarative architectural programming. I am not sure the term is right, but the split is real: the human owns the idea, the constraints and the taste; the model owns the typing.

What I learned

• Written boundaries matter more than clever prompts. Short per-module notes about what a module may and may not touch kept the codebase consistent across dozens of sessions.
• Standards in files beat repeating yourself. Every correction I made twice became a rule in a file.
• You still have to know what you want. The model is fast at building the wrong thing too. The product's strictness (one task, four lists, no editing) came from me, and it is what makes the app small enough to finish.
• Verification is the new bottleneck. I could not skim the code for bugs, so I used the product like a user would. Bugs I found while doing something else went into a KNOWN_ISSUES.md file instead of being lost.
• It is not free in effort. Time and attention still go into it, just not into typing. If you want the result to look and behave exactly the way you imagine, you have to work for it: form your ideas clearly, in small atomic pieces, and in a sensible order. Vague input gives vague output.

Is it mine?

This is the part I have not settled. The app came from my idea, my rules and my architecture, yet I did not write the code. The backend I could have typed myself; the frontend and the extension I steered by intuition and engineering sense, without reading the code. It feels strange to say "I made it" and "I did not make it" about the same thing.

My current answer: I am the author of the product and of the decisions, and the model is the author of the typing. A film director does not operate the camera either. But I notice that the line is blurry, and that it moves every few months.

Honest status

No users, no marketing, no revenue. It is early access and free, and it started as a tool for me and my son. If you try it, I would like to hear what is wrong with it.

• Web app: https://app.overdraft.nomad4.tech
• Landing page: https://overdraft.nomad4.tech
• Chrome extension: https://chromewebstore.google.com/detail/mgciphgekdeipgbablncehlmjmlciadb

Your turn

• Does it count as "yours" if you design everything and a model writes everything?
• A fast, polished app from a model, or a slower, smaller one written by hand: which would you ship?
• If you have tried a similar experiment, what broke first for you: the idea, the architecture or the review?

Tell me in the comments. And if you track your time, tell me what the one feature is that you could not live without.

Disclosure: this article was also written entirely by a model (Sonnet 5.5), from my notes and the project files, as part of the same experiment.