How I Built an App for My Diabetic Cat in 5 Days with Claude (And Accidentally Started a Startup)

A developer chronicles building a full-featured web application for monitoring feline diabetes in just five days using Claude Code, going from a quick prototype to a production deployment with AI analytics, interactive charts, and vet-sharing features.

My cat Manishka has diabetes. She's 13 years old, weighs only 3 kg, and every day I measure her blood sugar with a glucometer and inject insulin. For the first months, I recorded readings in a notepad on the refrigerator — just date, time, number. Then I realized you can't see the dynamics that way, so I switched to Excel with formulas and color-coded cells. Then I wrote a Python script that drew graphs and saved them as images.

All of this worked, but only for me. When it was time to go to the vet with a month's worth of results, I brought a printout of my Excel. I tried to explain: "Look, here in the morning it was 25, I injected one and a half units, by evening it dropped to 8, then shot up again..." The vet nodded, squinted at my markers — but it was clear he wasn't getting the full picture.

I thought — why not make a proper web application? I checked the App Store, Googled around. There are dozens of diabetes monitoring apps for humans, but almost nothing for animals. The ones that exist are either a paid subscription at 500 rubles/month or tailored for the American market.

I wrote a post on Pikabu showing my DIY solution. People started responding — turns out everyone is struggling with notebooks and spreadsheets. One girl wrote that she has a huge Excel file with formulas and she's afraid of losing it.

I decided: I'll build it for everyone.

Day One: Quick Prototype

It was Tuesday evening, November 12th. I'd recently received a $250 grant from Anthropic for Claude Code and decided to try it out. I opened the terminal and described what I needed: a web application for tracking glucose in a cat, with entry adding, a chart, statistics, and CSV export.

I honestly expected a discussion of requirements to start, technology choices, plan drafting. Instead, within two minutes I got a ready project structure. Another hour later, I had it assembled and running locally.

I open the browser — it works. A simple page with a form: enter date, time, glucose level, insulin dose. Hit "Save" — the entry appears in the table below. There's a "Show Chart" button — a static image pops up with a line. Basic, but functional.

By midnight, I was already entering Manishka's real data from the past week. Watching the chart being drawn, how the average glucose was calculated, what percentage fell within the target zone. I realized Excel was no longer needed.

I went to sleep thinking "I should add more features."

Day Two: Improvements and AI

Wednesday was spent in a mode of constant additions. In the morning, I decided to add AI analysis — let it look at a week's data and say whether the dynamics are stable, whether there are dangerous trends. I described the idea in one paragraph and got a ready integration with OpenRouter API. Even the AI prompt was already written — with an explanation of what feline diabetes is, what the norms are, what to watch for.

During the day, I added small but important things. Multiple pets instead of one (in case someone has two cats). CSV import to transfer old records. Validation to ensure people enter numbers, not random stuff like "cat123" in the glucose field.

The chart was tiny on the phone — I asked to make it mobile-responsive. The page reloaded with every new entry — I asked to make it smooth. Each fix took about 10-15 minutes: describe the problem, get the code, verify, commit.

By Wednesday evening, the app looked decent. I showed it to my wife — she said "convenient, let me record Manishka's readings through this instead of the notepad."

Day Three: Realizing the Problem

Thursday morning. I'm rereading comments on Pikabu. People are asking when they can register, whether they can show data to their vet right from their phone.

I'm sitting with coffee, looking at the code. And I realize that for public use, everything is wrong.

Authentication is cobbled together. The chart is a static image — you can't zoom or click. Most importantly — how do you give the vet access? Create them an account? A doctor won't register just for one patient. And performance — if a hundred people come at once, everything will crash.

I think for half an hour. The current code will need serious reworking. I need proper architecture — separate services, modern frontend, interactive charts.

I describe all the problems to Claude and what I want to change. I send it off expecting a response like "this is complex, let's do it gradually." I get: "Agreed, this is the right decision. Let's start with a new structure. We can reuse a lot of the logic."

We agreed on the architecture. Okay. Let's rebuild.

Days Three-Four: The Big Rewrite

Thursday afternoon, the rewriting began. Instead of one application, there were now several — one handles users, another handles data, a third renders the nice frontend.

The process wasn't as smooth as the first two days. The more complex the code, the more places where things go wrong.

Thursday evening. Migrating authentication — registration, login, tokens, token refresh. Testing: register, log in, log out, log in again. Works. In parallel, setting up the database in Docker, wrestling with environment settings.

Friday morning. Migrating the core logic. Interestingly, a lot of code from the old version transferred almost without changes — statistics calculations, data operations, CSV generation. Only the wrappers had to be reworked.

Friday afternoon. Writing the React frontend. This is where the fun began with TypeScript — it periodically complained about data types. Several times we went in circles: compilation error, fix, new error, fix. About four rounds before everything compiled.

Friday evening. Interactive charts with Plotly instead of static images. I launch it, open the page and... wow. You can zoom with the scroll wheel, select an area, hover over a point and see the exact value with the date. A completely different level.

By the end of Friday, I run a full test: register, add Manishka, enter records, view the chart, run AI analysis, export to CSV. Everything works. In two days — nearly a hundred commits and a complete application rewrite.

Day Five: The Final Push

Saturday. The app works great on the laptop, but it's far from a public launch.

First, I add the most important feature for me — sharing with the vet. The owner creates a link, the vet opens it without registering and sees the pet's data. The link expires after a chosen time. Plus a QR code for scanning at the appointment.

I describe the task, and within a couple of hours I get a ready solution. Testing: I create a link for Manishka, choose a 7-day duration, get a QR code. I open it in incognito mode — I see a beautiful public page with a chart, statistics, and a measurement table. At the bottom, a note about the service and a registration button.

Perfect! I imagine pulling out my phone at an appointment, showing the QR code — the doctor scans it and instantly sees everything.

But then I catch myself thinking: the public page is accessible to anyone with the link. Bots could find it, start scraping data, overload the server. I ask Claude to add protection — CAPTCHA appears along with a limit of 30 requests from one IP. Secure.

Next problem — AI analysis. It thinks for 5-30 seconds, and the user shouldn't sit staring at a spinning spinner that long. The first solution was simple — keep the connection open until the AI responds. But this created a problem: if you launch multiple copies of the service for load, each has its own state in memory. A user sends a request to one server, checks status on another — finds nothing.

Claude suggests Redis — a fast database that stores state and synchronizes all service copies. We add it, configure it. Now scaling is worry-free.

By noon, I set up automated tests — fifteen minutes for config, five more for secret tokens in GitHub. Now every commit is automatically verified.

In the evening, the most exciting part — the real deployment. I rent a server for 1,500 rubles per month, set up Docker on it, configure the domain diabnostic.ru, get a free SSL certificate from Let's Encrypt. Upload the code, launch.

Five minutes of waiting. I open app.diabnostic.ru in the browser.

It works. Just works. On the first try.

I register as a new user, add Manishka, enter data for the past month, watch the chart being drawn. Everything is in place, everything works. The app is on the internet, available to everyone.

Results

Five days of work:

  • 12,500 lines of code
  • 200+ commits
  • ~30 hours of net work time
  • Spent $100 from the Claude Code grant and 1,500 rubles on a server in Yandex Cloud

How I worked: I read every piece of code, tested it, ran it through SonarQube and Codex. Claude wrote, the tools checked, I decided. A typical feature — 4 iterations of half an hour each. Two hours instead of two days.

What AI did excellently: Docker configs, tests (82% coverage), library integrations, refactoring from Flask to microservices.

What required me: Architectural decisions, business logic (sugar norms, dosages), security, debugging in production.

Result: The app runs at diabnostic.ru. People can register and enter pet data. Vets scan a QR and see the full picture.

Plans: Injection reminders, mobile app, glucometer integration.

Conclusion: AI is an accelerator for those who know what they're doing. Without at least basic knowledge of web development and DevOps, I couldn't have done it. But with them — 5 days instead of a month. 70-80% time savings on routine tasks. Creativity and decisions stayed with me; AI just implements ideas into code faster.

FAQ

What is this article about in one sentence?

This article explains the core idea in practical terms and focuses on what you can apply in real work.

Who is this article for?

It is written for engineers, technical leaders, and curious readers who want a clear, implementation-focused explanation.

What should I read next?

Use the related articles below to continue with closely connected topics and concrete examples.