Otagai-sama board

Inspiration

I grew up in Soeda-machi, a small rural town in Fukuoka Prefecture, Japan. It's the kind of place where everyone technically knows everyone, and neighbors genuinely want to help each other out — but in practice, a lot of small everyday needs go unmet anyway. An elderly neighbor who can't drive to the clinic. Someone who could really use a ride or a hand carrying groceries, but has no easy way to say so, and no easy way for someone nearby to hear about it and offer.

There's a word for this spirit in Japanese: otagai-sama — roughly, "we're all in this together, so we look out for each other." The help that word describes already exists in towns like mine. What doesn't exist is a lightweight way to coordinate it — something that isn't a phone tree, isn't a Facebook group with all its noise and public exposure, and isn't a gig-economy app that turns neighborly favors into a transaction. I wanted to build the smallest possible piece of software that could plug that gap: a private board where people who already trust each other can post "I could use help with X" and have someone nearby say "I've got you."

What it does

Otagai-sama Board is a small, invite-only mutual-help board. Someone creates a private group and shares an invite code with the people they actually know — family, neighbors, a town's volunteer network. Inside that group, anyone can post a request for help (a ride, an errand, a chore, some company, or anything else), optionally with a deadline and a rough cost estimate. Others can respond directly with their contact info. There's no login — just the invite code to get in, and a private code (saved automatically by the browser) that lets the person who posted a request mark it resolved later. The app deliberately never touches money; if a favor involves buying something, people just settle up between themselves the way they always have.

How I built it

The backend is Python (Flask) with SQLite, and the frontend is TypeScript built with Vite — no framework, partly because I wanted the practice of working with TypeScript's type system directly rather than through a framework's abstractions. I built it in stages: the backend API first (groups, requests, responses), then the frontend screens on top of it, then a pass focused on accessibility and demo-readiness (larger text, high-contrast category colors, seeded demo data), and finally a round of deliberate bug- and edge-case testing — including checking that one group genuinely can't see or touch another group's data.

I hadn't built a full application like this before — most of what I'd written up to this point was smaller, self-contained scripts, not something with a database, an API, and a separate frontend talking to it. I used Claude (Anthropic's AI assistant) as something between a tutor and a pair programmer throughout: it would explain a concept or sketch out an approach, and I'd write the actual code into my editor myself, run it, and come back with whatever broke. That loop — try something, hit an error, understand why it broke, fix it — is where most of the actual learning happened.

Challenges I ran into

The hardest part wasn't syntax, it was design. Coming from small scripts, I didn't have much intuition yet for questions like: how should a database schema be shaped so it doesn't fight you later? How do you let people prove they own a request without making them create an account? (The answer I landed on — a random, one-time "edit token" instead of a password — was new to me, and made me think about security in a different way than I had before.) Deciding what the app should not do took just as much thought as deciding what it should do — I went back and forth on whether groups needed real logins, and on whether the app should handle payment for favors at all, before deciding both would work against the trust-based, low-friction feeling I actually wanted.

The other big challenge was translating a fuzzy, human problem into concrete features. "Neighbors should help each other more easily" isn't a spec — I had to keep asking what that actually meant in terms of screens, data, and rules, and to accept that the honest answer was often "build the simplest version, and see if it still solves the real problem." Alongside that, plenty of the difficulty was just ordinary beginner friction — getting a TypeScript build pipeline talking to a Flask server, PowerShell doing something unexpected, a database migration I forgot to re-run — the kind of thing that isn't glamorous but takes real time to work through when you're doing it for the first time.

What I learned

I came out of this with a much more concrete sense of how a full application actually fits together — a REST API, a typed frontend client, a database schema, and the security decisions that connect them — not just as concepts, but as things I've now debugged myself at 11pm. I also learned a lot about using AI well as a learning tool rather than a shortcut: the parts where I let myself just copy an answer without understanding it are the parts I had to come back and re-learn later, while the parts where I made myself understand why something worked stuck. Beyond the code, working on this reminded me that the most useful thing I can build isn't necessarily the most complex one — it's the one that fits an actual problem I've seen with my own eyes.

What's next

The next real test is putting an invite code in front of actual neighbors back home and seeing whether the everyday reality of "otagai-sama" fits into something this simple, or whether it needs to grow — reminders when a request is about to expire, a version in Japanese, maybe SMS for the neighbors least likely to open a web app in the first place.

1 earlier step 見た目を全面的に整える(高齢者にも見やすいUI) デモ用ダミーデータを投入 フロントのビルドをFlaskから配信する設定 通しテスト中 Demo video script MD Devpost story MD Readme MD Requirements TXT Uploads Image, Image +5 Memory Updated · Hackathon Rural Town Project

Built With

• css
• flask
• html
• javascript
• python
• restapi
• sqlite
• typescript
• vite