Two months ago I almost wired $1500 to an iOS consultancy. The pitch was solid: "We've seen the TestFlight 'app not available' bug a hundred times, we'll fix it in a day."
I didn't end up sending the money. Instead I built three Python scripts that did the same diagnostic work + actually shipped me forward. I want to walk through what made me change my mind, because I think a lot of indie devs are one decision away from making the wrong call here.
The pitch and why it almost worked
The agency salesperson was knowledgeable. They named the right symptoms. They knew the exact Apple Forum thread (674932). They had a 2-day turnaround promise.
What sold me was the relief — having someone else to handle this. I was 30 days into the bug, my apps were stuck in PREPARE_FOR_SUBMISSION, and every search result said "submit a Feedback Assistant ticket and wait."
The friction was real. The desire to outsource was real.
What stopped me
I asked one question on the discovery call: "Concretely, what diagnostic do you run first?"
The answer was a list of things you'd Google in 10 minutes: check tester state, check build state, check Apple ID. Nothing I hadn't already done.
That's when I realized the value being sold wasn't a fix. It was certainty — the comfort of having a paid expert tell me what I already knew. I was about to pay $1500 for emotional regulation.
If I had a real diagnostic that could differentiate "I missed something" from "this is the 4-year Apple bug," I wouldn't need the certainty. I could spend $1500 on something that actually moved the apps forward (a designer, a copywriter, a subscription to a research tool).
What I built instead
Three scripts, ~600 lines total:
1. asc_diag.py — runs through 8 known causes via JWT-authenticated ASC API. Outputs WARN/FAIL with fix instructions per class:
python asc_diag.py --all --skip-localizations
Tester state: ACCEPTED ✅
Build state: VALID ✅
Apple ID conflict: clean ✅
... etc.
If anything came back unclean, I'd know exactly what to fix. If everything came back clean (which happened), I'd know it wasn't on my side.
2. asc_submit_for_review.py — pre-flights all the App Store version requirements (build attached, screenshot sets present, version state submittable), then POSTs to /v1/appStoreVersionSubmissions:
# Dry run (verify, no submission)
python asc_submit_for_review.py --bundle-id com.example.myapp --dry-run
# Real submit
python asc_submit_for_review.py --bundle-id com.example.myapp
This was the actual workaround. Multiple devs in thread 674932 had reported that submitting for review (even without intending to release publicly) triggers Apple's metadata cache rebuild and unblocks TestFlight install.
3. asc_submission_monitor.py — polls the version state hourly via cron, writes transitions to JSONL. Tells me the moment Apple's queue moves from WAITING_FOR_REVIEW → IN_REVIEW → APPROVED:
# Cron-friendly
0 * * * * cd /path/to/autoapp && python dashboard/asc_submission_monitor.py
What this cost vs the agency
| Agency | DIY | |
|---|---|---|
| Hours invested | 0 (delegated) | ~6 hr writing scripts |
| Direct cost | $1500 | $0 |
| Information delivered | Diagnostic findings (delivered as report) | Diagnostic findings (delivered as runnable scripts) |
| Reusability | Single engagement | All future apps + future migrations |
| Public artifact | NDA'd | Open source on GitHub |
The 6 hours of script-writing was the most accidentally-leveraged time of my last 60 days. Every future app I ship will run through these scripts. Every other indie dev who hits the same bug can run them. Two of the three are now linked from a published dev.to article and a Substack issue, so the work compounds into top-of-funnel for my consulting practice.
When I'd actually pay an agency
I'm not saying don't hire help. I'm saying think about what you're paying for.
Pay for an agency when:
- The expertise is genuinely scarce (e.g., kernel-level iOS bug, custom Metal pipeline)
- You don't intend to ship multiple apps (one-shot context, no compounding)
- The bug is so obscure you can't even articulate the diagnostic question
- Your time is genuinely worth more elsewhere ($150+/hr revenue you'd lose by debugging)
Don't pay for an agency when:
- The bug has 400 forum posts and you can read them
- The diagnostic is "check 8 things via API"
- You're an indie dev with leverage compounding from open-source artifacts
- You suspect the fix is a known workaround (most "stuck for weeks" bugs are)
The meta-lesson
Outsourcing isn't free even when you have the money. You're trading a chunk of compound value (a tool you'd own forever) for a one-shot relief.
For indie iOS devs specifically: anything that touches App Store Connect API, build state, or TestFlight diagnostics is unusually high-leverage to learn directly. Apple's API is stable, well-documented (mostly), and the patterns repeat across apps. A script you write for app #1 saves you 5x more time on apps #2-#5.
If you want to copy the pattern, the three scripts are open. Drop them into any iOS portfolio repo and they'll work after you set three env vars.
What's next
I dry-ran asc_submit_for_review.py on my smallest app (DaysUntil) this morning. Pre-flight passed: build attached, screenshot sets present, state submittable. Tomorrow I flip the dry-run flag and Apple gets the canary.
If the workaround holds, I'll write the post-mortem with installation logs. If it doesn't, I'll have a much harder story — but the diagnostic + monitor stack is still the same regardless.
If you're 30+ days into a TestFlight install bug and considering paying an agency, drop a comment with what your asc_diag.py output looks like. Happy to help interpret. Free.
GitHub: github.com/jiejuefuyou
Top comments (0)