At the end of October, I wrote about joining my first hackathon, Built with Claude: Japan 2026. I had an idea for an app, but I wasn't quite sure how much I could actually build in a week.
On November 8, after seven very busy days, I submitted Kurashi.
It was an exhausting week, with a lot of experimenting, changing direction, and figuring things out as I went. I learned quite a bit about Claude Code, but also about how I approach software development myself.
Here's how it went.
From an idea to Kurashi
When I first moved to Japan from the Netherlands, even simple administrative procedures could be confusing. I didn't always understand the Japanese terminology, where I was supposed to go, or even which procedures applied to me.
Later, while working at a Japanese language school, I helped international students with many of these same problems. Sometimes that meant explaining a document. Other times it meant helping someone fill out forms or accompanying them to the ward office.
One thing I noticed was that people often didn't know they needed to do something in the first place.
For example, someone moves into a new apartment. They've got the keys and they're settling in, but they might not realize there are several things they need to arrange because their address has changed.
That's where the idea for Kurashi came from.
Instead of expecting someone to search for a procedure by its official Japanese name, I wanted them to start with something familiar, like "I moved" or "I left my job".
The app asks a few questions about their situation and helps them find relevant procedures, what to prepare, where to go, and what they might need to check first.
I started with Nagoya, since it's where I've lived and worked for years. The aim is to make it useful for anyone who finds these procedures confusing, whether they're new to Japan or have lived here their whole life.
The week didn't go quite as planned
I spent the first day almost entirely on planning. Claude helped me research the problem, compare existing services, and put together a specification.
That was useful, but as I continued, I started getting caught in a cycle of questions.
Every decision seemed to lead to several more. How should this unusual situation work? What about this exception? Which of these five options would I prefer?
I could see why Claude was asking, but eventually I was spending so much time deciding small details that I wasn't actually getting to try the application.
At one point, I was seriously wondering whether I could finish it in time.
So I changed my approach. Rather than trying to settle everything beforehand, I asked Claude to make a working version based on its recommendations. I would then try it, point out what wasn't working, and improve it from there.
That made a huge difference.
Once I had something on screen, it was much easier to say "This part is confusing" or "I expected this button to take me somewhere else" than to answer abstract questions about how a feature should behave.
It's a way of working I want to keep using beyond the hackathon.
Getting the design right took more than generating screens
Another thing I struggled with was the interface.
Claude could quickly produce different designs, but many of them felt familiar: cards, checklists, chat interfaces, and dashboards. They worked as concepts, but didn't really address what I wanted to help people with.
Eventually, I asked Claude to stop designing and interview me about my experience helping students.
We talked about what students struggled with, what explanations worked, and what actually helped someone take the next step.
That conversation was much more useful than another round of screen designs.
It helped me realize that the app shouldn't simply provide information. It should help someone recognize what they need to do, understand it, and feel ready to do it.
I also started using visual prototypes to compare alternatives instead of trying to explain every change in text. Showing Claude an example of what I liked often worked better than another long description.
I still had to make plenty of decisions myself, but I got much better at giving feedback that led somewhere.
What Claude Code helped me do
The amount of work I could get through in seven days was probably the biggest surprise.
I used Claude Code throughout the project: researching official information, developing the interface, implementing features, writing tests, checking accessibility, investigating bugs, and even editing the three-minute demo video.
I also experimented with dividing work between different models and agents. I used Opus for broader planning and coordination, Sonnet for more defined tasks, and a separate model to review parts of the specification.
That independent review was particularly helpful. It caught missing cases and questionable assumptions that had survived several rounds of planning.
I had already been using Claude Code for other projects before the hackathon, including a school management system, so I wasn't starting from zero. But working on a completely new application with such a short deadline gave me a much better understanding of how to organize the work.
I also learned that giving an AI more tasks doesn't necessarily make things easier.
At one point, I had accumulated so many planning documents, reports, and test files that keeping track of them became a problem of its own. I had to simplify the documentation and make it clearer which information was still current.
I found it particularly useful to ask Claude to prepare things for me to review visually, rather than producing another long report. For interface changes, a screenshot or working prototype usually told me much more.
The things I still had to check myself
Of course, not everything Claude produced was correct.
One memorable example happened while testing the lost-wallet flow. The app started treating a passport as lost even though the user hadn't selected it. Elsewhere, it made assumptions about someone's situation based on their residence status.
Those were important mistakes because Kurashi deals with real administrative procedures. A wrong assumption could lead someone to the wrong instructions.
I had to make the rules more explicit: the application shouldn't guess information the user hasn't provided.
Official information needed careful handling too. Claude was very useful for finding and comparing sources, but there were times when I found that its conclusions needed correcting.
For example, it initially concluded that some municipal waste-related data couldn't be used. After checking further, I found relevant open data and contacted Nagoya City to clarify what could be reused.
My experience helping students also came in handy. There's a difference between what a government website says and what somebody actually experiences when they visit an office or try to complete a procedure.
Both matter.
The testing process taught me a few lessons as well. At one point, tests appeared to pass, but an old development server meant we weren't actually checking the latest version of the interface.
Since then, I've been paying much more attention to what a test really verifies, rather than just whether it reports success.
Security was another important part of preparing the public prototype. I separated the private development repository from the public one, checked for accidentally exposed secrets, and reviewed how API usage would be protected and limited.
It made me more aware that getting an application to run is only one part of making it ready for other people to use.
What I took away from the experience
Looking back, I think the biggest change was in how I worked with Claude.
At the beginning, I tried to answer every question and plan every detail. By the end, I was much more comfortable giving it a direction, getting something working, testing it, and making changes based on what I found.
I also became better at deciding which tasks I could delegate and which ones needed my own attention.
Claude helped enormously with research, implementation, and exploring alternatives. That freed up time for the things I cared about most: whether the procedures made sense, whether the interface was understandable, and whether someone could actually use what we'd built.
The seven days also gave me more confidence to tackle larger ideas. I could explore things that I might previously have put aside because they would have required too much time to research or implement on my own.
I still have a lot to learn, particularly around testing, security, and managing larger projects. But I now have a much clearer idea of how to work with these tools effectively.
What's next for Kurashi?
Kurashi is still a prototype, and there's plenty I want to improve before treating it as a finished public service.
I'm working on making the navigation simpler, checking and expanding the administrative information, improving translations, and being clearer about which information has been verified and what still needs confirmation.
I'd also like to involve people who actually deal with these procedures, including international residents, schools, and eventually local organizations. Their feedback will be much more valuable than trying to anticipate every possible situation myself.
I started with Nagoya, but I'd eventually like Kurashi to cover other parts of Japan too.
I didn't finish the hackathon with a perfect application, but I did finish with a working prototype, a lot of new experience, and something I want to keep developing.
And that's a result I'm happy with.
---
See Kurashi
- Watch the three-minute demo
- Explore the Kurashi prototype — still under development; not an official government service
- View the public GitHub repository
More about the development process I also wrote a more detailed article on note about what I learned working with Claude Code during those seven days, including the experiments, mistakes, and practical changes that helped me work more efficiently.
Read my seven-day Claude Code retrospective on note (Japanese)