iTranslated by AI

The content below is an AI-generated translation. This is an experimental feature, and may contain errors. View original article
📃

A Complete Record of a Non-Engineer Building and Publishing an App with Claude Code

に公開

Long-Long Note
My self-made task management app, "Long-Long Note"

Someone who isn't an engineer built this app using only AI coding tools.

I am a writer. I don't have the ability to write code from scratch, and honestly, I'm not even confident if I can read it properly. Yet, I used Claude Code to develop a web app, deployed it to a production environment, and got it to a point where users are actually using it.

It took about 4 months. The total time spent working with Claude Code was about 20 hours (excluding time for research and confirming bug reproduction). This is the complete record of that journey.

What I Made

The app is a task management tool called "Long-Long Note." There is only one difference from a typical Todo app: When you complete a task, it is automatically recorded on a timeline. Checked-off tasks don't disappear; they stack up below with a date. This allows you to search for "When did I do that?" at any time.

The tech stack is React + Vite + TailwindCSS + Firebase (Authentication, Firestore, Cloud Functions, Hosting). It is PWA-compatible, so it can be used like an app if added to a smartphone home screen.

The Trigger

The trigger was an article by Allen Pike titled "How Leaders Manage Time & Attention". It interviewed 25 tech leaders about their task management methods, and about a third of them used a technique called "Long-Ass Note."

The method is simple: write down tasks in one long note, and instead of deleting finished tasks, add a date and move them to the bottom. This integrates task management with a work log.

I thought, "This is great," and tried to replicate it in Notion, but the manual process of moving completed tasks to the timeline was tedious, and I abandoned it after a few days.

"I wish it would just record automatically when I press the completion button."

That was the reason I started building this app. By the way, I initially tried to use the name "Long-Ass Note," but when I asked Claude, "Is 'Ass' a dirty word?", it told me, "Yes, it's slang for buttocks," so I renamed it to "Long-Long Note."

Completed tasks are registered in the timeline
Completed tasks are registered in the timeline

Building a Prototype with Claude.ai

The first thing I did was create a requirements definition document in a Claude.ai chat.

"I abandoned the manual transcription of the Long-Long Note I was running in Notion because it became too tedious. I want to build a web app where I can input tasks and have completed tasks recorded on a timeline simply."

When I told Claude this, it provided a requirements definition document organized by functional requirements, non-functional requirements, data structure, and development phases.

Next, when I asked, "Can you make a prototype with Artifacts?", it produced something that actually worked. This is where it got interesting—every time I made a request in the chat like "I want to reorder by dragging," "I want an edit function," "Show the due date in a smaller font," or "Can you add AI search?", the prototype would update.

Ultimately, I improved it through 22 versions within the same chat. From creating the requirements definition to completing the prototype, everything was finished in a single chat.

At this stage, it was just a simple version that saved data to the browser's localStorage, but the UI direction and necessary features were mostly solidified. Being able to "decide specifications while looking at something that works" is overwhelmingly faster than trying to finalize requirements through text alone.
The initial appearance of Long-Long Note
The initial appearance of Long-Long Note

Full-Scale Implementation with Claude Code

Since I was satisfied with the prototype, it was time to move to a full-scale development environment.

I consulted with Claude.ai in the chat, saying, "I should probably move this to a local environment, right?" It even created a Firebase migration guide (for beginners) for me. The guide explained the steps one by one, from checking Node.js to creating a Firebase project, setting up the React project, and deploying.

From there, I moved to Claude Code.

Claude Code is an AI coding tool that runs in the terminal and can directly read and write local files. I showed it the prototype code and the requirements definition document and said, "Build this with Firebase." It implemented everything at once, from project initialization to Google authentication, Firestore data structure, security rules, and deployment.

Here is the record of the first work day, October 2, 2025:

  • 17:00 Environment setup and project initialization
  • 17:35 Firebase project configuration
  • 17:50 Core application implementation
  • 18:30 UI/UX improvements
  • 18:50 User restriction functionality
  • 19:00 Deployment preparation

The MVP was running in about 2 hours. Google authentication, task CRUD, automatic timeline recording for completed tasks, and a responsive UI. Of course, there were bugs, and the code was rough. But for someone who can't write code, seeing a "working thing" appear at this speed was shocking.

A 4-Month Improvement Cycle

After the MVP was running, it was a daily process of improving it while using it. There were 12 work sessions over about 4 months. Each session lasted from 30 minutes to 4 hours. A total of about 20 hours.

The Story of Splitting a 1,170-Line "God Class"

In the initial MVP, all features were packed into a single file called TaskApp.jsx. 1,170 lines. Authentication, task management, timeline, search, drag-and-drop, UI rendering—everything was in one file.

When I asked Claude Code, "Isn't this file too big?", it told me, "It's a typical God Class," and proposed a three-stage refactoring plan.

  1. Separation of utility functions (dateUtils.js, constants.js)
  2. Extraction of custom hooks (useAuth, useTasks, useTimeline, useDragAndDrop, useSearch)
  3. Separation of UI components (TaskItem, TimelineItem, SearchBar...)

I proceeded while building and confirming the behavior at each stage, and finally, it went from 1,170 lines to 325 lines (a 72% reduction). The file structure also became clean.

At that time, I felt that "AI writes working code, but it doesn't think about design." It will tell you if you ask, and it's good at refactoring. However, it doesn't necessarily write with good design from the start. The decision to ask, "Isn't this too big?" is something a human needs to do.

Feature Additions

I added features that I wanted while using the app.

  • Manual notes to the timeline: I wanted to record events other than task completions.
  • Date jump and filters: As the timeline grew longer, I added a feature to jump to a specific date.
  • Export: Download in Text/Markdown format. Convenient for writing monthly reports.
  • Due date fade display: A 7-level display where tasks with distant deadlines appear faded and become darker as they approach.
  • Keyboard navigation: Arrow key movement between sections and form operations.
  • Offline support: Firestore offline persistence and authentication caching.

Battle with Bugs

Bug fixing was even more challenging than adding features.

Taps not working on iPhone: The touch event for dragging the entire task item was conflicting with the click on the completion button. It wouldn't respond unless tapped about four times rapidly. Solved with e.stopPropagation().

Duplicate registration when spamming the completion button offline: When Firestore was offline, the button could be pressed multiple times before the task completion process finished. Prevented by managing processing task IDs with a Set.

Drag-and-drop not working in production: Could not be reproduced locally. Due to production build optimizations, the asynchronous nature of React state updates became apparent. Solved by using useRef to update values immediately.

While Claude Code could provide fix suggestions once the situation was explained, it was a human's job to find the bugs. It starts with noticing something is wrong while using it yourself. AI doesn't tell you that a bug exists.

How to Review Code Written by AI

The biggest problem with solo development is that there is no one to review your code. In team development, a senior might point out, "Isn't this design a bit off?" When you're alone, you just end up approving the code the AI wrote because you think it "looks okay."

To be honest, at first, I was approving almost everything the AI wrote. If it worked, it was fine. I didn't really understand the internals.

Thinking this was a problem, I created a system for code reviews.

A Conversation Between Two Senior Engineers

The trigger was a code review for a different project (an interview note app). I asked Claude.ai, "I am a junior software engineer in my first year. I want to deepen my understanding by hearing a conversation (short critiques) between two seniors about the following code." It generated a review in the form of a discussion between Senior A (frontend-oriented) and Senior B (architecture-oriented).

This was fascinating. Rather than being told "you should do this" in a textbook fashion, hearing two people debate things like "What do you think of this?" or "But in this case—" made it much easier to understand why it should be done that way.

I liked this format so much that I systematized the prompt and registered it in the Claude.ai Project feature. Even for the development of Long-Long Note, I started putting new code through this review process.

The role-playing style code review really clicked
The role-playing style code review really clicked

"The Limits of Having Claude Review Code Written by Claude"

However, I am aware of the structural limitations of this method. Having an AI review code written by an AI means they might share the same blind spots. The conversation between the senior engineers is, after all, also generated by AI.

Even so, I believe it is certainly better than "no review at all." At least, through these reviews, I've come to intuitively understand design basics like "God classes should be split," "seek fundamental solutions over symptomatic ones," and the "DRY principle." Even if I can't write code, my sense for noticing "Isn't this design a bit weird?" has started to grow.

Turning It into a Claude Code Skill

Initially, I was pasting code into Claude.ai projects for review, but in February 2026, I ported this as a "skill" for Claude Code. By making it a skill, it can now directly read and review the actual codebase. It eliminated the need to copy and paste files and allowed for critiques based on the overall picture of the code.

I added an AI search function to the app. It's a feature that allows you to search the timeline using natural language, such as "What tasks did I complete last week?" or "When did I do the work related to XX?"

The first choice I made was the Google Gemini API. I set it up by deploying to Firebase Functions and calling it from the frontend. The deployment itself was successful, but when I actually tried searching, no results came back. I couldn't identify the cause, so I put it on hold for a while.

About two months later, I switched to the Claude API (Sonnet 4.5), and it worked on the first try. I had to adjust the prompt (telling it things like "don't return Markdown, return plain text"), but the basic operation was smooth.

It was a slightly amusing experience to instruct Claude Code to "use the Claude API" and have it implement the Claude API for me.

As a cost-saving measure, I've set a rate limit of three searches per user per day, and only the most recent 500 timeline items are sent to the AI.

I also added a reflection function using AI
I also added a reflection function using AI

Security and Public Preparation

Regarding security, my basic policy was "don't implement it yourself."

  • Authentication: Google authentication only. Entirely outsourced to Firebase Authentication. I don't take responsibility for password management.
  • Data Isolation: Using Firestore security rules, each user can only access their own data.
  • Personal Information: Only email addresses, display names, and task contents are stored. No payment features.
  • Scope of Publication: Invite-only. This limits the scope of impact.
  • API Protection: Rate limits on Claude API calls. This reduces the risk of excessive billing due to abuse.
  • Monitoring: Error tracking with Sentry.

I also created a privacy policy and terms of use. I specifically stated the scope of data sent for AI search (search query + up to the 500 most recent timeline items).

It's impossible for an amateur to achieve perfect security. Therefore, I focused on not carrying risk. Minimize personal information, don't build authentication from scratch, don't handle payments, and don't make it fully open. Rather than trying to do things I couldn't do, it was more realistic to reduce the risk itself.

System architecture diagram of Long-Long Note
System architecture diagram of Long-Long Note

Automatic Generation of Work Logs — The Material for This Article

The reason I was able to write this article is that all the records of the development process were preserved. It was the AI that kept those records.

Since the early stages of development, I have been using Claude.ai's project feature to generate work logs. After finishing work, I would copy the entire Claude Code terminal screen, paste it into Claude.ai, and ask it to "write a log." Claude would then generate a Markdown format log after confirming the date, work time, and progress rate.

Initially, it was a manual process. I had to copy and paste everything and answer questions about the date and time every single time. However, as I repeated this, a template implicitly began to form, and the log's structure stabilized.

In January 2026, I realized, "If I make this a Claude Code skill, I won't need to copy and paste anymore," and ported it as a skill. I built in a system to automatically retrieve git log and diff --stat, so a log is now generated with just a single command at the end of a session.

As a result, work logs for all 12 sessions over four months remain in a perfectly consistent format. Everything is recorded: work time for each session, features implemented, bugs encountered and their solutions, lessons learned, and tasks for next time.

"I had the AI record the process of creating an app that records what I've done." I only realized this Matryoshka structure later on.

Looking Back with Numbers

Item Value
Development Period About 4 months (Oct 2025 – Feb 2026)
Work Sessions 12 sessions
Total Work Time About 20 hours
Git Commits About 60
Application Code JSX 5,500 lines + JS 3,400 lines = Approx. 9,000 lines
Test Code 21 files, approx. 3,500 lines
AI Tools Used Claude.ai, Claude Code, ChatGPT, Claude API

Reflection

What Went Well

I got what I wanted. This is the biggest factor. "Long-Long Note," which I had abandoned in Notion, has become an app I can use every day. When I complete a task, it's recorded on the timeline automatically. The initial goal has been 100% achieved.

The cycle of "I want to do this" → "Done" is fast. If I communicate a request for a new feature, it gets implemented in minutes. Refactoring, adding tests, and fixing bugs too. This speed is a game-changer for someone who cannot write code.

My understanding of technology has deepened. I still can't write code, and it's questionable whether I can even read it, but at least I've come to understand the general "vibe" of what is being done. React component design, Firestore security rules, optimistic UI updates, and the inner workings of PWAs—I learned a lot while using them.

Limitations

I cannot judge the quality of the design myself. Looking at the code the AI produced, I can't tell if "this is a good design." That's why I had ChatGPT review it or created a code review skill. Even so, there must be things I've overlooked.

I don't understand the causes of bugs. I can notice that "it's not working," but I can't trace "why it's not working" on my own. While Claude Code can fix it if I describe the symptoms, a sense of it being a black box remains.

The number of lines I wrote myself is almost zero. Out of the 9,000 lines of code, there is almost no part where I actually hit the keys on the keyboard to write it. Honestly, I don't know if I can say I "developed" this. However, I did everything else—requirements definition, design decisions, testing, bug discovery, security design, and preparation for publication.

Is This "Vibe Coding"?

According to the definition of vibe coding as "letting AI write code with momentum and intuition," the first MVP was exactly that. I reached deployment in two hours.

But the four months after that were different. I refactored, wrote tests, created a system for code reviews, thought about security, and wrote a privacy policy. I filled the gap between "it works but can't be released" and "it's ready for release" one step at a time.

It is often said that vibe coding is compatible with "throwaway" code, but I cannot make an app I use every day a throwaway. That's why I continue to maintain it—in my own way as a non-engineer.


"Long-Long Note" is operated on an invite-only basis. If you are interested, please contact me through the inquiry form.

The introduction to the app's features is summarized in this article.

https://blog.aroka.net/entry/2026/01/11/212640

Discussion