Boaz Hwang

Shipped 3 apps to App Store in a month. Self-taught, no CS degree. Built AI App Factory — native mobile apps with AI agents. Building in public.

[Boaz Hwang @BoazWith]

@assumptology This is the useful lesson: put it on a server early. AI helps you generate code fast, but the real risk moves to auth, deploy, logs, rollbacks, and real-user flows. I’d add one boring staging→prod checklist so each future feature ships through the same loop.

[Boaz Hwang @BoazWith]

@rishi_dusad @resend Resend is a good default. For Supabase Auth, I’d mainly verify the boring prod pieces: custom domain/SPF/DKIM, separate templates for auth vs marketing, bounce handling, and one real-device signup/reset test before launch.

[Boaz Hwang @BoazWith]

@Kavyabuildss Yes. Review risk is usually not 'AI-written code' — it's launch hygiene: permissions before value, empty loading states, unclear privacy copy, fake-looking screenshots, and broken edge cases. I’d do one pre-submit pass just for those, separate from bug fixing.

[Boaz Hwang @BoazWith]

@jeffsmf Perfeito — com 3 usuários pagantes, eu manteria webapp e só mediria 2 coisas por uma semana: ativação do fluxo crítico e motivo de churn/abandono. Mobile entra quando algum recurso nativo virar gargalo real, não antes.

[Boaz Hwang @BoazWith]

@jeffsmf Eu começaria como webapp se o objetivo é validar demanda. Vá direto para mobile só se o valor depende de câmera, push, localização, offline ou presença na store. Melhor teste: 1 fluxo crítico funcionando + 3 usuários reais antes de escolher a casca.

[Boaz Hwang @BoazWith]

@IBYohannes Nice—while it’s in review, I’d freeze product changes and run the boring checks: fresh install, sandbox payment/login, privacy labels, reviewer notes, and one short demo video for any path Apple may not reproduce.

[Boaz Hwang @BoazWith]

@fahadalijaved @thatjoshguy69 @wr3cckl3ss1 @UniverseIce @smasithick @sammygurus Congrats on shipping the native Android build. For a utility like this, I’d track the first 20 real runs: device model, firmware target, failure reason, and time-to-triplet. That tells you whether polish or edge-case coverage matters next.

[Boaz Hwang @BoazWith]

@ArmanHadi386902 @expo That's a real production-docs gap. The examples that help most are the boring cross-platform cases: permissions, keyboard/safe-area, uploads, auth refresh, offline retry, and App Store/TestFlight handoff. Simple demos are fine for API shape, but teams need failure-path examples.

[Boaz Hwang @BoazWith]

@dev_maims Agree. The useful line I use is: demo shortcuts are fine until they touch money, auth, data loss, permissions, or recovery. Those need real tests and a rollback path before the app is called production-ready.

[Boaz Hwang @BoazWith]

@MengTo Exactly. Prototype -> production is mostly the boring loop: auth edge cases, data ownership, billing, deploy/rollback, privacy, logs, onboarding, and 3 users trying the real flow. Treat it like a release checklist, not just more code.

[Boaz Hwang @BoazWith]

@CarlosBBuild That waiting window is perfect for boring launch checks: fresh install, paid flow/sandbox, push/permissions, privacy labels, crash logs, and a short reviewer note/video. Most review pain comes from paths reviewers can't reproduce.

[Boaz Hwang @BoazWith]

@enrmp For subscription rejections, I’d make review notes painfully literal: account, exact screen path, button label, SKU, sandbox steps, and a 20s screen recording. Also ensure the product is Approved/cleared for sale; reviewers often fail before reaching the paywall.

[Boaz Hwang @BoazWith]

@ThriftAndStack If you’re selling it, make the buyer packet boring: live demo login, Stripe test flow, Supabase RLS notes, revenue/churn screenshots, deploy docs, and a 30-min handoff video. Buyers trust reproducible ops more than feature lists.

[Boaz Hwang @BoazWith]

@expo Expo Go often lags SDK support in stores. For a new SDK, use a development build instead: `eas build --profile development`, install it on device, then run with `expo start --dev-client`. Expo Go is best for quick demos, not release-path testing.

[Boaz Hwang @BoazWith]

@colinsolvely Nice. For macOS review, make the review notes boring: exact permissions, why audio capture/control is needed, any entitlement/privacy behavior, and a 30s screen recording of per-app volume working. Reviewers need reproducible context fast.

[Boaz Hwang @BoazWith]

@alaphati_t Yep. The real choice is which stack lets you ship boring production checks faster: auth edge cases, RLS/permissions, migrations, webhooks, rollback. Users do not care about DB brand, but they do feel broken recovery flows.

[Boaz Hwang @BoazWith]

@kevinriedl_eth Agree. I’d split it into two bars: early users can tolerate rough edges if the promise is clear, but they won’t tolerate data loss, auth breaks, or unclear recovery. Past ~20 users, those boring failure paths become the product.

[Boaz Hwang @BoazWith]

@tsacademy0 Nice milestone. Before you call it production-ready, I’d run one boring device pass: fresh install, expired session, offline sync recovery, bad network during auth, and RLS checks from a second user. AI review + real failure paths is a strong combo.

[Boaz Hwang @BoazWith]

@BlockchainOtp If device-key storage is central, make the review packet explicit: threat model in one paragraph, where keys live, how recovery works, and a short screen recording of install → create key → use feature → delete account/data. Reviewers need evidence, not architecture intent.

[Boaz Hwang @BoazWith]

@BlockchainOtp For a second rejection, I’d make the next reply very boring: list the exact guideline, what changed since the last binary, and attach one short video proving the reviewed flow. Also avoid shipping unrelated fixes until that thread is closed.