Why I did it
Until recently, my company's tasks, hours and expenses lived in three places: a Google Sheet, the calendar and email. Each one did its part, none of them held the whole picture. To know where something stood I had to open all three, and remember where I had written it down.
I looked at off-the-shelf software. None of it fitted the way I work: it asked me to change my habits to follow its logic, not the other way round. So the question changed. If the right tool does not exist, can I build it? Today, with AI, you can. And that is where a tailor-made application makes the difference: “The custom solution fits your company 100%.”
That is how Activity 2.0 was born, the application I now use to follow tasks, hours and expenses.
The Activity 2.0 dashboard: for the team, expenses to approve and draft hours to confirm. Demo data.
One week: how it really went
These were the tools: Claude Code, an assistant that writes code from instructions, and a standard web framework, running locally on my computer. All of it with the contribution of Grok Bot.
I will not tell the week day by day, because the calendar is not the point. The point is this: I only understood that the application worked at the end of the week, when I started using it for real, on my own work. Before that I saw screens that looked fine. With real tasks, it became clear what held up.
It is the first thing I would tell anyone who tries. An application is judged on everyday work, not on the demo.
The hard part was not the code
The assistant writes the code, and writes it fast. The hard part is knowing what to ask for. And, almost more, what not to ask for.
Resisting extra features
Before you start, it pays to fix the MVP, the minimum viable product: the smallest version that really does the job the application is for. It sounds like a detail for developers. In fact it is the decision that saves the project.
With AI, adding a feature takes a few minutes, and that is exactly why it is dangerous. Every addition looks free, but it pulls you away from the problem you started with. This is how I learned it: “The urge to add extra features: it seems so easy, but you lose your way and you load the product with features you will use 3 times in your life. You have to resist and stick to the MVP.”
Telling the AI what not to do
A good request does not only describe what the application must do. It also says what it must not do, and where the limits are. If you leave room, the assistant may fill it with things you did not ask for. If you set the boundaries, it works inside them, and the result looks like what you had in mind.
Telling what matters from the noise
Here experience counts more than technique. Which activities really matter in my work and which are noise is something I know after years of doing it; the AI cannot know it for me. It can build almost anything I ask. Choosing what to ask is still my job.
If I started again
I would start from one rule, written before the first line of code: “A well-thought-out project and MVP, and then no detours. Additions come after real use.”
Well thought out means spending more time deciding what goes in than building it. New ideas are not thrown away: you write them down, and come back to them when real use tells you whether they are needed.
What it means for a small business
Can a small or mid-sized company take the same path? I believe so, with one condition I would not compromise on: without at least one technical person to rely on, it is better not to start. I do not mean an IT department. I mean someone who can read what the assistant has produced and notice when something does not add up. They do not have to write the code for you: they are the person you ask before trusting what you see on the screen.
The owner, for their part, brings what no tool knows: how the company really works, what matters and what is noise. Without that, even the best technical person builds the wrong thing, only faster.
Then there is a question to ask early: where does the data go? If sensitive information ends up in the application, about clients, patients or staff, it is worth thinking about at the start, not afterwards. I write about it on the page on on-premise AI.
Where to start
To an owner who wants to try tomorrow morning I would give one piece of advice: pick one process, small and annoying, and start there. Not the whole management system, not the project that transforms the company. That one thing that eats time every week and that nobody wants to do. For me it was tasks, hours and expenses scattered across three tools.
A small process has two advantages. You find out quickly whether the application works, because you use it straight away on real work. And if it does not, you have lost little, and learned what to ask for next time.
If you are not sure which one is yours, the page on AI for small businesses has a 5-question test that helps you see where AI can start in your company. If you already have the process in mind and want to tell me about it, you will find me on the Contact page.