Developing an Event Web App with Claude

1. Introduction

To digitally transform competitive activities conducted at team-based offline events, I planned and implemented a web-based application as a solo developer. In the application, participating teams purchase resources with virtual currency, create deliverables, and compete for points while responding to real-time changes in conditions. Previously, these activities were conducted using paper ledgers and manual calculations, which meant that facilitator errors were directly reflected in the scores. Participants also had no way to check their resource status in real time. Having experienced these inefficiencies firsthand, I began this project by wondering, “If it’s a system of this scale, couldn’t I build it properly on my own?”

At the same time, I personally wanted to verify how much productivity could actually be increased by using AI not merely as an auxiliary tool, but as a development partner throughout the entire process of design, implementation, and debugging. The constraint of having to handle everything alone, from planning to deployment, instead became a valuable opportunity to experiment with various approaches to collaborating with Claude and evaluate their effects without exaggeration. Within a short schedule, this was by no means a lightweight task: it required an administrator dashboard, asset management for each participating team, near-real-time event processing, and stability under simultaneous connections from many users.

This article focuses less on the project’s technical details and more on how I used Claude as a development partner throughout the process. From a practical perspective, I would like to share how collaborating with AI affected actual productivity in a situation where I had to handle everything alone, from planning and design to implementation, debugging, and deployment.

2. Project Overview

The frontend uses React and TypeScript, the backend consists of serverless functions based on Next.js API Routes, and the database is serverless PostgreSQL. Because of the practical constraint of a limit on the number of serverless functions available on the deployment platform, I decided early on to group APIs by domain rather than by individual feature. This design discussion itself was decided through conversations with Claude, comparing several alternatives, and became an important starting point that shaped the overall structure of the project.

3. Principles for Collaborating with Claude

In this project, Claude went beyond being a code autocomplete tool and served as a collaboration partner for everything from design discussions to debugging and refactoring. The collaboration principles I established through repeated trial and error are as follows.

“Rather than trying to get a perfect answer in a single attempt, spending time improving the precision of the questions ultimately proved faster.”

Looking back, the key to using Claude effectively ultimately came down to “how much specific context I provided.” Vague requests produced vague results, while clearly presenting constraints and existing patterns produced results that could be applied directly to practical work. This was more than a simple tip; it meant that communication skills required when incorporating AI into the development process had themselves become a new productivity factor.

4. Real-World Collaboration Examples

4.1 Design Discussion: Organizing the Scope of Structural Changes Together

In the initial data model, a single entity simultaneously held affiliation information and assets. As the actual requirements became more specific, however, it became necessary to separate “who participates in the activity” from “who owns the assets.” This type of structural change affects all related query logic and permission systems in a chain reaction. Instead of immediately asking Claude to modify the code, I first asked it to “help organize a list of the files and logic affected by this change.” By applying the resulting list sequentially, one item at a time, I was able to complete the migration without omissions or conflicts. This experience made me realize how important it is to first draw a “map” together before delegating execution to AI.

4.2 Adapting to the Latest Libraries: Narrowing the Gap Between Documentation and Actual Behavior

The scheduling library introduced for event scheduling happened to undergo a major version upgrade, creating points where the previously known usage differed from its actual behavior. In such cases, I provided Claude with both the error messages and the version in use, then worked through the differences between the API described in the official documentation and its actual behavior one by one. This approach was particularly effective for subtle but critical details such as the location of trigger configuration, how cancellation conditions are specified, and time zone conversion. When working with the latest technologies, it is important to recognize that there may be a gap between the point at which the AI’s knowledge was learned and the actual latest version, and actively sharing error logs and version information had a significant impact on the speed of problem solving.

4.3 Step-by-Step Debugging: Start with the Symptoms and Reach the Conclusion Later

When a bug occurred, instead of immediately asking Claude to “fix it,” I first described the symptoms as specifically as possible, narrowed down the possible causes together, and then proceeded with the modification. Bugs involving asynchronous processing timing or database constraints often retain their root cause while only the visible symptoms disappear if a solution is applied too hastily. Asking Claude to explain the cause first, verifying that the explanation matched the actual logs and data, and then making the change significantly reduced the rate of recurrence.

4.4 Deciding When to Refactor: Extract It When the Repetition Appears for the Third Time

As the number of features grew, similar UI patterns—filters, loading handling, and confirmation dialogs—began appearing repeatedly on different screens. Each time, Claude and I assessed whether it was time to extract the pattern into a reusable component. The criterion we established was “the moment the same pattern appears on a third screen.” Once this criterion was clearly included in our conversations, Claude’s responses to similar requests changed as well: it began mentioning the possibility of reuse first. I was able to confirm that, as collaboration with AI continues, the context accumulated in the conversations itself functions somewhat like a team convention.

4.5 Collaboration from a Code Review Perspective: Ask for the Rationale, Not Just the Result

Rather than applying Claude’s suggested code as-is, I made a habit of asking why it had chosen that structure. For example, when Claude suggested a join method for a particular query, I asked, “Why did you choose this approach, and what alternatives are there?” The answers sometimes revealed a simpler alternative. This was not significantly different from the questions asked during a code review with a human colleague. Going through a process of verifying the rationale instead of accepting AI-generated results as-is was ultimately important not only for code quality but also for maintaining the developer’s own understanding.

It was also effective to break a large request into verifiable units rather than issuing a single broad request. For example, instead of asking Claude to “build the entire exchange feature,” I divided it into stages such as “register a transaction → retrieve the transaction list → execute the transaction.” This allowed me to verify the actual behavior at each stage before moving to the next, making it possible to detect errors early. I realized that the ability to align the size of deliverables with the verification cycle is just as important in AI collaboration as it is in collaboration with people.

5. A Quantitative Review of the Project

The completed system can be summarized numerically as follows. Within the constraints of the deployment platform, the backend API was condensed into 11 files, which handle 11 domains in total: authentication, organizations, teams, members, resources, deliverables, transactions, combinations, exchange rates, events, and logs. The database consists of 20 tables, while the frontend is divided into 9 types of administrator screens and 5 types of participant screens, for a total of 14 primary screens. Despite significantly redesigning the data model twice during the development period, I was able to stay on schedule thanks to the collaboration habit of listing the scope of changes first and applying them sequentially, one at a time.

• API files: 11 (integrated design by domain)

• Main data tables: approximately 20

• View configuration: 9 administrator views, 5 participant views

• Data model redesign: 2 times (① separated the player-team-package ownership structure, ② changed the exchange purchase/sale method to a unidirectional sales structure)

6. Lessons Learned: Practical Insights from Collaborating with AI

• The specificity of context determines the quality of the output: Even with the same question, there was a significant difference in output quality depending on whether the constraints and existing code context were provided together.

• “Drawing the map” comes before execution: For tasks with a broad impact range, such as structural changes, going through a step to organize the scope of impact together instead of immediately requesting execution helped reduce rework.

• Conversations become accumulated assets: When I explicitly organized the design intent and rationale behind decisions during conversations, I was able to obtain consistent results in subsequent related tasks without repeatedly explaining them.

• The newer the technology, the more human verification is needed: The newer the library version, the greater the potential gap with the point at which the AI's training data was collected, so it was important to develop the habit of cross-checking error logs against official documentation.

• AI is closer to a collaboration partner than a tool: Productivity improved much more when I treated AI as a partner that participates in the decision-making process and helps build a shared rationale, rather than merely as a tool that writes code on my behalf.

7. Conclusion

The greatest lesson I learned from this project was the conviction that “how to communicate with AI” influences both the quality of the output and development speed more than “what to entrust to AI.” By adhering to three principles—providing specific context, clearly communicating constraints, and performing step-by-step validation—I was able to complete a production-level service within the निर्धारित timeframe even as a solo developer.

I believe this is not an experience limited to a specific project, but a collaboration methodology applicable to work as a whole going forward. The ability to use AI as a practical development partner is ultimately directly connected to the ability to think and communicate clearly, and based on this experience, I intend to gradually apply this approach across the team's work as well.

PYS