masato

I'm Masato, a software engineer based in Tokyo. Heading to LA for grad school this fall. I grew up in Tokyo, spent a year in Australia, worked as a data engineer, then quit my job to study computer science in Budapest on a scholarship. Now I'm back in Tokyo, freelancing and building my own products on the side. I want to share what I'm building, what I'm learning along the way, and the life decisions I'm figuring out in real time. Nice to meet you.

closed 3 product folders today. kept 1 open. the closed ones aren't dead. they're paused. they wait for the open one to find users. permission to do less. #buildinpublic

claude api thing i missed for months: prompt caching auto-applies to system messages over 1024 tokens. moved instructions to system. ~90% reduction on repeated calls. docs said it. i hadn't read carefully. #claudeai

the builders i actually learn from: post once a week. ship something concrete. don't tell you how to think. the ratio is the lesson. 80% building. 20% sharing. not the other way around. #indiehackers

tried to write a cold message to a potential user this morning. opened the editor. closed it. opened again. sent. message took 5 minutes. decision took 30. #buildinpublic

next.js 15 routing pattern: co-locate components with routes. app/dashboard/page.tsx app/dashboard/_components/chart.tsx app/dashboard/_lib/utils.ts deletion stays safe. discovery stays obvious. #nextjs #webdev

my X engagement went up. my product MRR didn't. these are different funnels. following ≠ buying. attention ≠ conversion. still figuring out where the bridge is. #buildinpublic

supabase RLS pattern that's been working: 1 policy per access pattern, not per table. "users see their own rows" applies to read, write, update, delete across most tables. abstract early. RLS is part of the data model. #supabase #postgres

shipping the smallest version of one product today. not a launch. not a flagship. just one feature, end to end, working in production. momentum > perfection. #buildinpublic

my actual stack (3 products in production, 0 paying users): next.js supabase claude api stripe vercel resend monthly cost: ~$20. revenue: $0. build is solved. distribution isn't. #buildinpublic #saas

the muscle solo dev is hardest to build: deciding what NOT to build. every feature i ship is one i maintain forever. cutting feels like loss. it's actually focus. #indiehackers

claude code session pattern from this week: write the spec in markdown first. one feature per session. close the terminal when done. short focused sessions ship. open-ended sessions wander. #claudeai

reading patrick mckenzie's "don't call yourself a programmer" today. his point: companies hire problem solvers, not programmers. "i write python" < "i improved [outcome] by [number]." reframing how i describe my own work. #devlife

day 33. yesterday: picked 1 of 4 products to focus on. today: shipping the smallest version end to end. closing tabs is harder than opening them. #buildinpublic

end of day: picked 1 product to focus on. ran a claude code session that worked. posted ~20 things. mom test interviews tomorrow. small day. consistent. #buildinpublic

next.js routing pattern that's been helping: co-locate components with routes. app/dashboard/page.tsx app/dashboard/_components/chart.tsx app/dashboard/_lib/utils.ts deletion stays safe. discovery stays obvious. #nextjs #webdev

the unsexy part of shipping: every product is "almost ready" for 6 weeks. the last 20% takes 80% of the time. learning to ship at 80% and fix the rest in production. #buildinpublic

tools i'm using daily: - claude code (90% of dev) - supabase (everything backend) - next.js + vercel (deploy) tools i tried and dropped: - cursor (claude code does the same) - multiple email services (resend covers it) simpler stack = faster shipping. #indiehackers

stripe webhook handler pattern: every handler stores event.id first. returns 200 immediately if seen. stripe retries on any non-2xx. without idempotency, you process the same payment multiple times. #stripe #devlife

solo SaaS with $0 revenue: shipping the product was 30% of the work. finding users who care is the other 70%. i'm only realizing this 4 products in. #buildinpublic

reading the mom test before user interviews this week. the rule: never ask "would you use this?" people lie to be nice. ask "when was the last time you had this problem?" watch if they can even remember one. #indiehackers