At BugSplat, we always push teams to set up crash reporting and a real bug-tracking workflow early in development. So you can imagine how it landed when I ran into the exact same argument at Denver Startup Week, made by someone with no reason to flatter me.
I was chatting with the founder of a startup that has a few projects in flight. He mentioned they'd just kicked off a new application and things were moving fast. One problem: in a team meeting the week before, he'd realized they still hadn't wired up crash reporting or connected it to their bug tracker (they're on Jira). In his words it was a casus belli, and he'd had the team drop what they were doing to get crashes tracking and logging automatically.
What got me wasn't that a crash reporting enthusiast in a BugSplat hat was hearing crash reporting praised. It was how hard this founder leaned on doing it early. His reasoning was simple: the longer a bug goes undetected, the more expensive, tangled, and miserable it gets to fix. Catch it early, while the project is still in the developers' hands, and you save the time, the headache, and the "whoops, sorry about that" email to users after release.
Setting up crash reporting early won't catch everything right away, especially before you're really into testing. But the moment something does break, it gets reported and logged in Jira (or whatever tracker you use) so you can fix it as you go instead of discovering a pile of it later.
There's more than one way to run this, and I'll be fair about it. Some teams worry that stopping to fix bugs too early kills momentum, and plenty of our own users would rather batch them into a dedicated bug-squashing phase. That's a real position.
But I'll make the case for early anyway: bugs are easier to fix when fewer cooks have been in the kitchen. The code around them is younger, the dependencies are simpler, and the cost of the fix is lower on every axis. Set up crash reporting before you need it, and the day you need it, it's already working.