I built my own tool without being a programmer

There are videos promising an app built with artificial intelligence in ten minutes, no coding required. I wanted to test that with something I actually needed, not yet another to-do list. It worked, yes, but not in ten minutes, and here I explain what it cost, where I got stuck and what I'd do today if I were starting from scratch.

You've probably seen the typical video: someone types a sentence, hits a button, and a few minutes later a beautiful app is up and running. "No coding required," says the title.

That way of working is called vibe coding: you tell the AI what you want in plain language, it writes the code, you test it and ask for changes, barely reading what it produces. Andrej Karpathy coined the term in early 2025 and it stuck.

I took it seriously. No toy examples: I picked a problem that was eating up my time every week. Let me warn you up front so nobody feels cheated: the tool exists, I use it every day, and it took me about 14 hours spread over three weeks. Quite a bit more than ten minutes.

My problem was deeply unglamorous. I work with several clients and I need to know how many hours I spend on each one, on what, and to have a summary at the end of the month that I can send them or use for invoicing. I kept it in a spreadsheet that had grown with no order: one tab per month, columns that no longer meant anything and formulas that broke if anyone inserted a row.

Between logging, correcting and putting together the monthly summary, I was losing about 40 minutes a week, plus a whole afternoon at the end of the month. And on top of that, I often logged things two days late and from memory.

I looked at existing apps. I tried two fairly well-known time trackers: one was excellent but designed for teams, with more menus than I would ever use; the other wouldn't let me export the summary in the format my clients ask for unless I paid for the higher plan. Neither was bad; they just weren't made for me.

And that's the idea I kept: the best first tool is small, specific and just for you. Nobody else has to like it. It has to solve your problem, full stop.

To build it I used Claude Code. For anyone who doesn't know it: it's an Anthropic assistant that works directly on the files on your computer. It's not a chat where you copy and paste bits of code; it reads the folder, creates files, edits them, runs commands and checks what it's doing. It's what's called an agent, an AI that takes several steps on its own to complete a task, and it asks permission before anything sensitive.

I chose it because I mostly work with Claude and because I had already used it in I built a website with the help of AI. I want to be clear: I didn't write the code. The model wrote it; I described, tested and complained.

The first request went roughly like this: "I want a small web app for personal use where I log the hours I spend on each client, with date, client, task and duration. At the end of the month I want to get a summary per client that I can paste into an email. Only I will use it, on my computer".

Before it started writing, it asked me questions: where to store the data, whether I wanted to be able to edit entries already logged, whether I needed multiple users. Some things I decided myself: that the data would be stored in a single file that's easy to back up, that the main screen would be a three-field form, and that the first thing it had to do well was logging, not the summary. Others, like the programming language or how to organise the folders, I left to it: I had no basis for an opinion.

The best advice I can give about this part is the one that took me longest to learn: ask for a minimal version first. What it really comes down to, if you want to build an app with AI without drowning, is asking, testing and fixing in small steps. The first version only logged hours and listed them. That's it. And that was already useful to me.

Here comes the crash, which is what this blog is for.

It took about 11 work sessions. The first three were wonderful: I asked for something, it appeared, it worked. I got carried away. I started asking for more and more ambitious things in the same conversation: filters, colours per client, a chart, export to a spreadsheet. All at once.

The jam came with the monthly summary. I asked it to group the summary by client and round to quarter hours. It did. The next day I asked for the ability to edit an old entry, and while fixing that, the summary started counting edited hours twice. I didn't notice until one client showed up with 31 hours in a week when I'd worked 18 for them.

That's when I understood the risk of vibe coding that everyone mentions and nobody tells you about from their own skin: when something fails and you don't understand the code, you depend on the machine to fix it, and sometimes it fixes one thing and breaks another. I spent two sessions going round in circles: it fixed the count, editing broke; it fixed editing, the double count came back.

I was about to give up. One night I closed the laptop convinced I was going back to the spreadsheet. What got me out of the hole wasn't a trick but a change of method:

• Save a copy of every working version, with a date, before asking for anything new.
• Change one thing at a time and test it before moving on to the next.
• Test with my real data from any given month, not with the three sample clients it made up.

With those three rules, what had been stuck for two sessions was solved in one afternoon. I asked it to go back to the last good copy and add only the editing, with a test comparing the total before and after.

The tool lives on one of the servers on my internal network, not on the internet. I have eight machines at home, so it makes sense to use them, but the underlying reason is different: the data belongs to my clients and I didn't want to expose it to anyone. It can only be opened from my network; from outside, it doesn't exist.

My routine is simple. When I finish each block of work I open a browser tab, type client, task and duration, and close it. It takes about 20 seconds. At the end of the month I press a button and copy the summary.

How much does it save? Compared with the 40 minutes a week and the end-of-month afternoon, it now takes me about 10 minutes a week in total, month-end included. And what can't be measured in minutes: I log hours the same day, so the numbers are more reliable.

Maintenance has needed little. One bug with the change of month, which didn't close summaries properly for 31-day months, and one change I asked for myself to add a notes field. Both times I went back to Claude Code with the same discipline: copy, one change, test with real data.

This is the serious part.

Without coding you can get to a useful, personal tool. I've lived it. But there's a clear line, and it's best not to cross it blindly: as soon as other people's data, passwords, payments or anything published on the internet come into play, you need technical judgment or someone who has it.

Here's an example of my own. In one of the early versions, to email me the summary, the code stored my email account password in plain text inside a file. The machine didn't warn me. I spotted it because, ever since the website, I always check where the keys end up. If that folder had ended up on the internet, the problem wouldn't have been a miscount.

As for the two routes to build an app without coding, the short version is this. No-code platforms give you ready-made pieces: it's hard to break anything, but you're limited to what they offer. Asking the model for the code gives you total freedom, in exchange for ending up with things that work without you really knowing why.

And one nuance I think matters: "without coding" doesn't mean "without learning anything". Along the way I ended up understanding what a database is and why you should back it up, what the difference is between something working on my computer and working on a server, and what environment variables are, which is where passwords should go and not in the code. I'm not a programmer, but they no longer sound like gibberish to me.

If you're up for it, these are the steps I would follow today:

1. Pick a problem that only affects you. If it goes wrong, the only one who suffers is you.
2. Describe it as you'd explain it to a colleague: what you do now, what bothers you and what you want to happen.
3. Ask for a minimal version. Just enough to be useful.
4. Test it with your real data, not the sample data.
5. Save a copy of every version that works.
6. Grow one step at a time: one change, one test.

And one rule I don't negotiate on: start in a test folder. Never on your company's files or on your only copy of anything.

What's true in the promise: yes, someone who doesn't code can build a useful tool by talking to AI. I use mine every day.

What's smoke: the ten minutes and the "effortless". It took me about 14 hours and the money for the Claude subscription I was already paying, with no additional cost. I'd do it again, but starting with the minimal version and with backups from day one.

If you're interested in a sister case, with its own stumbles, I tell it in I built a website with the help of AI.