masato

masato

@masatobuilds.bsky.social

shipping AI products solo. next.js · supabase · claude api USC MSCS '28 · ACL 2025 co-author Tokyo → Los Angeles, the long way around. posts on the indie hacker grind, AI tools, and the unsexy parts of solo dev. work inquiries → hey@kyren.app kyren.app

17 followers6 following68 posts

something i didn't expect from doing NLP research: evaluation methodology became my default product habit. 30 annotated test examples before any feature. felt like overkill in grad school. now it's how i ship without bugs.

View full thread

kashite tracks lending between friends. yomu reads documents and answers questions. phrasely rewrites awkward english. no stack. no day count. no $0 mrr.

the thing that actually compounds in claude code, after 3 months of daily use: it's not the tools. not the agents. not the skills. it's having a written spec before you open the terminal. #buildinpublic

i mean a 5-line spec: input · output · constraints · edge cases · done. 5 minutes to write. agents that get this spec: ship. agents that don't: wander, break unrelated files, eat your context window.

the irony — i learned this from an OOP exam in budapest 3 years ago. the professor made us draw UML on paper before any code. i thought it was archaic. turns out "design before you type" is the unlock for working with agents. he was just early.

day 37. start of may. april ended at 36 X followers, 8 here. started both at single digits. 6x on the top of the funnel. 0x on revenue. posting works for attention. nothing else. the bottom of the funnel is where may goes. #buildinpublic

before opening a session: git diff --stat HEAD paste the output as the first message in the chat. claude doesn't have to re-read the whole tree — it knows what's actively changed.

the responses come back tighter. less "i see you have this file" preamble. more direct edits. context is the budget. spending it on relevant diff > spending it on scanning. obvious in hindsight. took me a month to start doing it. what's your equivalent context-saving move?

day 35. last day of april. month in numbers: 6 → ~50 followers 3 products live 0 paying users 2 weeks of consistent posting building was easier than expected. distribution still hasn't clicked. #buildinpublic

the rule: write a 5-line markdown spec before opening the terminal. input · output · constraints · edge cases · done condition. 5 minutes to write. what i used to skip turned into the highest-leverage step.

day 34 of building publicly. 3 products live. 0 paying users. working on the focused one this week. freelance work picked up too. balance is the actual job. #buildinpublic

the rule: write a 5-line markdown spec before opening the terminal. input / output / constraints / edge cases / done condition. 5 minutes to write. saves hours of fixing.

took a week away from building. came back to 4 products at 80% complete. distance helps you see which one actually matters. the answer was not the one i expected. #buildinpublic

something i've been noticing in my own work: the weeks i shipped 1 concrete thing moved more than the weeks i talked about shipping every day. closing that gap. #buildinpublic

claude code session that worked today: spec written in markdown first. 20 minutes focused coding. done. vs sessions where i "just start typing": 2 hours, mostly fixing what i broke. short sessions, clear contracts.

something i'm reminding myself: my stack is irrelevant until someone pays for the output. stack is leverage. revenue is the test. still working on the second part. #buildinpublic

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.

3 days on bluesky. 5 followers, 6 posts. different platform, different reset. posting what i'm actually doing here too. no expectations. small base, quiet feed. the early days here feel like 2010 twitter.

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

sitting with 4 products today: kashite (lending tracker) yomu (AI doc reader) phrasely (rewrite tool) sabaku (focus app) picking 1 by tonight. the others go to a paused folder. closing tabs is harder than opening them. #buildinpublic

pgvector vs pinecone real-world choice: under 1M vectors → pgvector over 10M vectors → pinecone between → depends on query patterns most "AI startups" have under 100K vectors. you don't need a vector database. you need a database with vectors. #ai #postgres #rag

most "build in public" reveals: what's working: announced loudly what's not: silence what almost killed the company: never tweeted the curated honesty is still curation.

the "I'll just rebuild it" trap: every time you decide to rewrite, you're making a bet that the new version will reach feature parity faster than the old one accumulates new bugs. that bet rarely pays off.

supabase RLS pattern that scales: don't write 50 policies per table. write 1 policy per access pattern. policy: "users see their own rows" applies to read, write, update, delete across most tables. abstract early. RLS is code. #supabase #postgres

stripe webhook gotcha that bit me twice: your handler must be idempotent. stripe retries on any non-2xx response. if your db write succeeds but you return 500, you'll process the same payment 3 times. always check event.id before writing. #stripe #webdev

You are up to date.