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.

end of day: 1 product getting all my attention now. 1 feature shipped to staging. 1 cold message sent. 0 paying users still. day 33 done. tomorrow again. #buildinpublic

@AIGrowthCoach yeah, the wall-of-conditions version doesn't even hit you until ~5 tables. by then it's painful to refactor. setting the pattern from day one saves a future weekend.

@masatobuilds this is the trick i wish someone told me on day one with supabase. modeling RLS per access pattern keeps the policy file readable instead of becoming a wall of conditions per table. saving this.

supabase pattern: write 1 RLS 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

@rivestack stealing "they can't fake their own behavior from last tuesday." that's the whole mom test compressed. specific past > hypothetical future, every time.

@masatobuilds the time machine question is the killer. people answer the hypothetical wrong, but they can't fake their own behavior from last tuesday

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

@rivestack the silence vs feedback gap is huge. one thing that helped: treating cold outreach replies as the metric, not the message itself. brain handles "sent 5, got 1 reply" better than "maybe nobody read it."

@masatobuilds shipping has a clear feedback loop, cold outreach has a delayed mostly silent one. brain learns to avoid the silent thing even when it's the higher leverage move

the gap that keeps showing up: i can ship a feature in an hour. i'll postpone sending one cold message for a week. skill is not the bottleneck. something else is. #indiehackers

what's working in my own posting: technical posts → quiet but useful build log posts → loud opinion posts → silence people don't follow you for being right. they follow you for being there. #buildinpublic

week so far: picked 1 of 4 products. shipped the smallest version of it. tried (badly) to email potential users. posted ~100 things across platforms. mom test interviews next. small steps. #buildinpublic

postgres index tip i learned the hard way: multi-column indexes work left to right. if your index is (a, b, c) and you query WHERE b = x AND c = y, the index doesn't help. column order = query pattern. #postgres

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

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

the gap that keeps showing up in my own work: i can ship a feature in an hour. i'll postpone sending one cold message for a week. skill is not the bottleneck. something else is. #indiehackers

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