shingo irie

App legal checklist for developers. Here are 5 things you should have in place before launch ↓ - Terms of Service — define liability and prohibited actions -Privacy Policy — explain how user data is handled -Required business disclosure — once you add paid features, legal obligations may apply -Store policy compliance — make sure you meet App Store / Google Play review rules -External API terms — check commercial use limits and non-compete clauses in advance Trying to prepare everything at once can slow you down. For an MVP, it’s more realistic to start with the core legal docs, then improve them step by step as the product grows. One big trap: once you enable payments, you may be required to provide business disclosure information. “I’m still small” usually doesn’t help. For solo founders, that can mean dealing with address/privacy issues. Another risk: if you build on an external API without reading the terms, you may later discover that commercial use is restricted—right when revenue starts growing. Always have a backup option. App stores also have lots of hidden rules. Kids apps may face ad restrictions, social apps often have extra moderation/privacy requirements, and many categories come with detailed compliance hurdles. It’s worth checking these before you build.

Personally, since I'm running multiple services, I do subscribe to Vercel, Neon, and Resend. Even so, the total comes to under ¥10,000 (~$65) a month.

How far can you run an indie app for free? - Up to a few thousand monthly visitors and dozens of concurrent users, the Vercel + Neon + Clerk stack runs at $0/month with no issues. - Now that Clerk's free tier covers up to 50K MAU/month, there's no reason to DIY auth with Auth.js — prioritizing speed with Clerk is the standard move. - With Vercel Blob's free tier expanded to 1GB, image-light apps can stay entirely on Vercel for free. Cloudflare R2 is also great with a very generous free tier. - Mobile apps still require App Store / Google Play developer fees. Firebase is a solid free starting point for backends, but watch out — it's pay-as-you-go. - The trigger to go paid shouldn't be "am I hitting limits?" — it should be "am I generating revenue?" Design around that. - If you're maxing out the free tier but not monetizing, don't bet on "paying for more capacity will make it grow." Question whether the product itself is viable first. - Many free tiers flip to pay-as-you-go once exhausted — so plan your monetization path early. Also, free services have shut down or raised prices without warning before. Always have a backup option and be ready to migrate.

For indie dev, AI costs are actually higher than infrastructure costs. Between ClaudeCode, Codex, APIs, etc., if you use them freely without thinking, you can burn through tens of thousands of yen a month. And apps don't monetize quickly. So — build while also building marketing tools early, and have them work for you.

I can now use my personal AI on my phone while out — giving instructions and generating blog posts and short videos. Next step: having it all run automatically while I'm asleep.

The essence of requirements definition isn't adding features — it's largely the work of deciding how much you can cut from ideas you've had. The more features you add, the more complex it gets and the further you drift from completion. Cutting relentlessly is something you absolutely cannot do without conscious intention.

Using indie dev as a weapon in your job search... - With AI, simply "finishing an app" matters less. What's scrutinized now is the quality of your decisions: why you built it, why you chose that tech/architecture. - Interviewers value "failed" projects more than successful ones. A project you abandoned shows your reasoning process for course-correcting and cutting losses — something you can speak to concretely. - The "no team experience" weakness of solo dev can be addressed by carefully maintaining Issues and PR-based branching — that demonstrates your understanding of dev processes. - What sets you apart in problem framing is whether you were the first user yourself. A tool that solves your own real inconvenience gives you far more depth to talk about than an app built for a hypothetical audience.