https://bryantchen.cc/en Bryant's personal website — indie dev, AI, product thinking en Thu, 14 May 2026 07:07:20 GMT https://bryantchen.cc/en/thoughts https://bryantchen.cc/en/thoughts/2026-05-12-form-is-medium Tue, 12 May 2026 00:00:00 GMT Form is the medium — it decides what users and readers actually see. On WeChat, people look at the image and read the post body; on Video Accounts, people watch the video and largely skip the text. Different platforms also mean different things behind the scenes: different moder... https://bryantchen.cc/en/thoughts https://bryantchen.cc/en/thoughts/2026-05-01-from-50-to-80 Fri, 01 May 2026 00:00:00 GMT  These days, building a 50-point demo with AI may only take half a day, or even an hour or two. But from 50 to 80, there is often a huge chasm. Most of the time, shipping a 50-point demo does not prove much. **Shortening... Image generated with GPT-image-2.]]> https://bryantchen.cc/en/thoughts https://bryantchen.cc/en/thoughts/2026-05-01-look-before-vibing Fri, 01 May 2026 00:00:00 GMT Vibe coding has a common detour: you ship the demo first, skip the thinking and research along the way, and just keep asking the AI to tweak it. But sometimes it pays to stop and look at how reference products solve the same thing — how others handle the same kind of problem. It... https://bryantchen.cc/en/thoughts https://bryantchen.cc/en/thoughts/2026-04-29-completeness-and-humanity Wed, 29 Apr 2026 00:00:00 GMT Two recent thoughts: 1. Ideas are easy to copy. Completeness and details are not. Marketing and distribution channels are not. The data and corpus you have accumulated cannot be caught up with overnight either. Spinning up a demo has never been easier — everyone can say "I just ... https://bryantchen.cc/en/thoughts https://bryantchen.cc/en/thoughts/2026-04-29-no-one-leads-forever Wed, 29 Apr 2026 00:00:00 GMT I have been moving some of my dev tasks onto Codex lately, and I keep feeling it: a complete toolchain (calling image-gen APIs directly, reading markdown natively, clean integrations with all kinds of tools), a reliable user experience (highly visual), plus a GPT-5.5 brain that i... https://bryantchen.cc/en/thoughts https://bryantchen.cc/en/thoughts/2026-04-24-product-as-marathon Fri, 24 Apr 2026 00:00:00 GMT When I build products, I think about running. 1. The core of long-termism is to stay on the track — to finish the marathon with a calm, positive, and self-paced mindset. 2. Building a product often feels confusing at the first step. Dive in, and you start to collect unexpected l... https://bryantchen.cc/en/thoughts https://bryantchen.cc/en/thoughts/2026-04-22-clawputer-100-stars Wed, 22 Apr 2026 12:00:00 GMT  ClawPuter officially crossed 100 GitHub stars today. I just kept shipping casually, and the milestone quietly arrived on its own. It is the first project I built from zero to one that reached three d... https://bryantchen.cc/en/thoughts https://bryantchen.cc/en/thoughts/2026-04-22-follow-best-practices Wed, 22 Apr 2026 00:00:00 GMT A recent reflection: I am not a fan of chasing best practices, which makes me move too fast and step on avoidable landmines — especially on procedural stuff. Two examples, for future me to remember: 1. **Google AdSense account**: I moved too fast and filled in Hong Kong details,... https://bryantchen.cc/en/thoughts https://bryantchen.cc/en/thoughts/2026-04-20-ship-before-perfect Mon, 20 Apr 2026 02:15:00 GMT  This X post got a small burst of attention this afternoon. The numbers are not huge, but it is already my best-performing post ever. Publishing really is more important than perfecting. Before post... https://bryantchen.cc/en/posts/ios-proxy-client-pitfalls https://bryantchen.cc/en/posts/ios-proxy-client-pitfalls Thu, 16 Apr 2026 12:00:00 GMT Self-hosted VPS proxy, phone couldn't connect. Tried 3 free iOS apps — all failed. Turns out it was a core engine compatibility issue. Full troubleshooting journey, 5-app comparison, and a lesson about false economy. Based on my real troubleshooting experience, co-created with Claude (AI). All technical details verified in a live environment. ## Background I run Xray on a VPS with two proxy protocols: - **Shadowsocks (SS)**: Classic protocol, port `18388` - **VLESS Reality**: Next-gen protocol, port `443`, disguised as normal HTTPS traffic Mac connects via SSH tunnel — rock solid. Then one day, my phone just stopped connecting. Not "intermittent." Just dead. ## The Investigation ### Step 1: VPS is Fine SSH in, quick check: ```bash systemctl status xray # ✅ running ss -tlnp | grep xray # ✅ ports 18388, 443 listening curl -s https://www.google.com # ✅ 200 ``` Nothing wrong server-side. ### Step 2: Three Free Apps, Three Failures Tried every free iOS proxy client I could find: | App | SS | VLESS Reality | |-----|-----|---------------| | **Streisand** | timeout | timeout | | **V2Box** | timeout | timeout | | **Hiddify** | timeout | timeout | All dead. ### Step 3: Reproducing on Mac Installed the `xray` client on Mac to test the protocols directly: ```bash # SS test curl -x socks5://127.0.0.1:10808 https://ifconfig.me # ❌ Empty response, exit code 52 # VLESS Reality test curl -x socks5://127.0.0.1:10809 https://ifconfig.me # ✅ Returns VPS IP ``` **Finding 1**: SS is broken from Mac too — it's a protocol-level issue, not a phone problem. **Finding 2**: VLESS Reality works perfectly from Mac. ### Step 4: Loopback Test on VPS Running an xray client on the VPS itself, connecting to its own SS port (bypassing external network): ```bash # VPS localhost → localhost:18388 → internet curl -x socks5://127.0.0.1:10900 http://httpbin.org/ip # ✅ Success ``` SS works locally but not externally — **the firewall is specifically blocking SS protocol traffic** through deep packet inspection. ### Step 5: Identifying the Phone Issue VLESS Reality works from Mac but not from phone. What do all three free apps have in common? **They all use sing-box as their core engine.** sing-box is an open-source proxy core. But it has compatibility issues with Xray's Reality implementation, specifically the `xtls-rprx-vision` flow. ## The Fix Bought **Shadowrocket** ($2.99, US App Store). Copied the VLESS Reality link, opened the app, auto-imported. Connected in 30 seconds. The previous troubleshooting with free apps had taken over two hours. ## Two Key Takeaways ### 1. Shadowsocks Is No Longer Safe DPI firewalls can now fingerprint and block SS protocol traffic. Symptoms: - TCP handshake succeeds (port is reachable) - But protocol-level data never comes back (empty response) - No client can fix this If you're still using SS, migrate to VLESS Reality or Hysteria2. VLESS Reality disguises traffic as normal HTTPS (SNI points to microsoft.com), which current firewalls can't detect. ### 2. Free iOS Clients Share a Fatal Flaw | App | Core Engine | VLESS Reality | |-----|------------|---------------| | Streisand | sing-box | ⚠️ Incompatible | | V2Box | sing-box | ⚠️ Incompatible | | Hiddify | sing-box | ⚠️ Incompatible | | Shadowrocket | Proprietary | ✅ Works | | Surge 5 | Proprietary | ✅ Works | All free apps depend on sing-box, which has compatibility issues with Xray's Reality. It's not any single app's bug — it's a core engine issue. No amount of app-switching helps. ## Full iOS Proxy Client Comparison | | Shadowrocket | Surge 5 | Streisand | V2Box | Hiddify | |---|---|---|---|---|---| | **Price** | $2.99 one-time | $49.99/yr | Free | Free | Free/OSS | | **Core** | Proprietary | Proprietary | sing-box | sing-box | sing-box | | **SS** | ✅ | ✅ | ✅ | ✅ | ✅ | | **VLESS Reality** | ✅ | ✅ | ⚠️ | ⚠️ | ⚠️ | | **Hysteria2** | ✅ | ✅ | ✅ | ✅ | ✅ | | **Stability** | High | High | Medium | Medium | Low | | **Rating** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐ | ⭐ | **Shadowrocket is the best value**: $2.99 one-time purchase, proprietary core, full protocol support, frequent updates. Surge is more powerful but subscription-based. ## Pitfall Checklist | Pitfall | Symptom | Root Cause | Fix | |---------|---------|------------|-----| | SS blocked | All clients timeout | DPI firewall blocks SS protocol | Switch to VLESS Reality | | Free apps fail on VLESS | Streisand/V2Box/Hiddify timeout | sing-box incompatible with Xray Reality | Use Shadowrocket | | Port reachable ≠ proxy works | TCP connects but proxy fails | TCP handshake ≠ protocol works | Test with actual xray client | | Hiddify dev broken | Nothing connects | iOS dev build sing-box bug | Don't use dev builds | | Xray degrades over time | Misbehaves after 45 days | Process state degradation | Periodic `systemctl restart xray` | ## The Bottom Line $2.99 on a proxy client isn't wasteful — **it buys back two hours of debugging and the frustration of cycling through three broken apps.** Free tools aren't bad. But when your server uses a newer protocol like VLESS Reality, their shared core engine becomes the bottleneck. You can't see this from the app's UI — all you get is a meaningless "timeout." The most expensive cost is never the tool's price tag. It's the time you spend trying to avoid paying it.]]> https://bryantchen.cc/en/posts/adsterra-integration-guide https://bryantchen.cc/en/posts/adsterra-integration-guide Thu, 16 Apr 2026 00:30:00 GMT After getting stuck on AdSense phone verification, I switched to Adsterra and had ads running in one evening; later I found the ads caused forced redirects on the user side, so I turned them off and started rethinking AdSense. This article is organized from my actual project conversation with Claude (AI). All data, lessons learned, and code examples are from integrating ads into [AIBT](https://aibtapp.com). > **Update, afternoon of April 16, 2026**: After shipping this, I found that the ads added through this approach kept triggering forced redirects on the user side. I am still not sure whether I configured something incorrectly, or whether this is caused by the ad format / ad network itself. Either way, it clearly hurt the user experience, so I turned this ad setup off for now. > > My conclusion has changed after this: Adsterra is fast to integrate and useful for validating the ad monetization pipeline, but if user experience is the priority, the better long-term path is still to get Google AdSense working. ## How AdSense Blocked Me Before I Even Started My project is [AIBT](https://aibtapp.com), an MBTI-style personality test for AI. 72 SEO pages, three languages (EN/ZH/JA), deployed on Cloudflare Pages. Content quality wasn't the issue. The issue was AdSense's registration flow. **Once you pick a payment country, you can't change it.** I chose Hong Kong (I have an HK bank card), and then the phone verification demanded a +852 number. I only had +86 and a US number. Verification failed. The account was stuck: I couldn't change region, couldn't delete and restart (one AdSense account per Google account). If you don't have a phone number that matches your chosen payment country, AdSense might not work for you. ## Why I Turned to Adsterra at the Time | | Google AdSense | Adsterra | |---|---|---| | Approval time | 1-4 weeks | **A few hours** | | Minimum traffic | No official minimum but low-traffic sites often get rejected | **None** | | Phone verification | Must match payment country | **Not required** | | Payment threshold | $100 | **$5** (Paxum/USDT) | | Payment methods | Bank wire only | PayPal, USDT, Wire, Paxum | | Ad quality | High | Medium, and redirect-style UX issues need extra caution | My original judgment was: AdSense is enterprise-grade gatekeeping. Adsterra is self-service. For a small site with under 100 daily visitors, Adsterra looked like the better short-term ROI because at least you could get ads running. But that was only true if the question was "Can I quickly make the ad pipeline work?" If user experience matters, especially for a product that needs users to stay, share, and return, forced redirects can cost far more than the tiny amount of ad revenue they bring in. ## Registration (5 Minutes) ### 1. Create an Account Go to [Adsterra](https://beta.publishers.adsterra.com/referral/DUEf5kCsSX) → Sign Up → choose **Publisher**. What you need: - **Email**: your regular email - **Login**: a username - **Messenger**: pick any (Telegram/Twitter/Skype), fill in your handle. They won't actually contact you - **Country**: your actual country. **This doesn't lock your payment method**. Unlike AdSense, Adsterra lets you choose PayPal/USDT/Wire at any time No phone number, no bank info, no identity verification. Just email verification. ### 2. Add Your Website Websites → ADD WEBSITE → enter your domain and category. Adsterra's categories are rough (Social / Movies / Downloads...). There is no "Technology" or "Entertainment." Pick **Other** if nothing fits. **Turn off Adult ads** unless you run an adult site. ### 3. Choose Ad Formats (The Key Decision) This step determines the balance between revenue and user experience. **Relatively restrained:** - **Native Banner**: blends with content and looks like a recommendation widget. CTR is relatively good, and visual disruption is lower - **Banner**: traditional display ads. Pick 728x90 (desktop leaderboard) + 300x250 (universal rectangle) + 320x50 (mobile strip) **Now I would be extremely cautious with:** - **Popunder**: opens a new window when the user closes/switches tabs. CPM is 3-5x higher than banners, but it hurts UX. I used to think it could be limited to SEO landing pages. Now I would be more conservative: if the product is early and user trust is still fragile, don't use it **Avoid:** - **Social Bar**: floating notification bar that blocks content - **Smartlink**: redirects users to ad pages, completely wrong for content sites The problem I ran into was this: even without intentionally adding a redirect page, users still saw forced redirects. That does not prove every Adsterra setup behaves this way, but it does prove one thing: after adding ads, test the site yourself on real devices. Especially test mobile, incognito windows, different network regions, and first-visit behavior. ### 4. Wait for Activation Submit and refresh after 3 minutes. Status changes to **Active**. Faster than making a cup of coffee. ### 5. Get the Code Each Ad Unit has a **GET CODE** button → copy the HTML/JS snippet. ## Placement Strategy: What Goes Where **Core principle: the more you need users to share/interact on a page, the fewer ads it should have.** | Page Type | Native Banner | 300x250 | 728x90 / 320x50 | Popunder | |---|---|---|---|---| | Homepage | Use cautiously | ❌ | ❌ | ❌ | | Core experience (test results) | Use cautiously | ❌ | ❌ | ❌ | | Content detail pages (SEO) | Testable | Testable | Testable | Not recommended | | Utility pages (stats/FAQ) | Testable | ❌ | Testable | Not recommended | **Why be cautious even on the homepage and results page?** Homepage popunder = user's first visit gets a popup, they leave immediately. Results page is where users screenshot and share. Sharing generates free traffic that is worth more than ad revenue. Too many ads kill the sharing impulse. After running into forced redirects, I am more convinced of this: early products should not trade first impressions for a few cents of revenue. You can add ads later. Lost trust is much harder to recover. **Why can detail pages be tested?** These pages get traffic from Google search. Users are "strangers" with higher ad tolerance. Long content has enough space. This is where ad revenue usually comes from. But "testable" does not mean "acceptable at any UX cost." The smallest viable approach is to place one restrained display ad first, watch user paths, bounce rate, and whether any abnormal redirects appear, then decide whether to expand. ## Technical Implementation ### Responsive: Different Ads for Desktop and Mobile ```html

``` ### Batch Injection: Don't Add Manually to 200+ Pages AIBT has 72 personality pages × 3 languages = 216 HTML files. Write a Python script: ```python from pathlib import Path AD_CODE = '''''' for html_file in Path('personality').rglob('index.html'): html = html_file.read_text() if 'ad-identifier' not in html: # idempotency check html = html.replace('