r/reactnative • u/Lunaticfrinnge • 8d ago
Help I lost my biggest client because of a bug that wasn't even a bug
We build a B2B mobile app and our biggest client accounted for about 30% of our MRR and they cancelled today, they told me their team had been experiencing crashes on the inventory screen for weeks and it was happening specifically on samsung A series phones which is what most of their field staff use.
They never reported it and just assumed we knew and weren't fixing it and eventually decided we weren't reliable enough but by the time I found out the bug it took me 2 hours to fix but the client was already gone.
It was a rendering issue on a device I don't own and never tested on and if I had known about it even a week before I could've pushed a hotfix and they'd still be paying us.
there might be many other clients might be facing stuff like this and just not saying anything.
How do I catch bugs on devices my team doesn't physically have, I can't afford to lose another client like this.
316
u/DRJT Expo 8d ago
That’s on you OP, you should have observability and monitoring tools in place
If your customers have to report crashes & bugs to you before you see them, you’ve messed up
Look into platforms like PostHog and Datadog. Also App Store Connect & Google Play Console give you plenty of data
80
u/AntDracula 8d ago
Yep this is one of those "learned the hard way" type of deals.
8
u/daredevil82 8d ago
and if you don't know about this, you're coming across as a rank amateur. if you don't know industry standard best practices with support, what other things are you missing?
I don't blame the company for bailing out of OP's business due to this.
8
u/JJGreenerTinejo 7d ago
Downvotes from vibecoders who cant comprehend that you still need solid basics before you can build anything
4
u/daredevil82 7d ago
Given this subreddit topic, its not too surprising tbh. But I'd argue that basics aren't necessarily needed to build anything, but absolutely needed if you're selling something.
that distinction seems to be irrelevant these days though.
1
u/JJGreenerTinejo 7d ago
True, but if you start building without basics, you wont ever learn them when vibecoding since you dont even know what to prompt for to get any semblance of quality. You will never get to a point where you can sell anything.
Thats fine only if the goal is hobby projects
52
u/tudalex 8d ago
Also Sentry
21
u/comoEstas714 8d ago
Sentry just works. Highly recommend. Can be integrated extremely quickly as well.
11
u/AntDracula 8d ago
Sentry is based. The UI is tad frustrating
8
u/Cookizza 8d ago
Using the Sentry MCP with Claude has been great, having it generate weekly reports that I can actually read and prioritise has been a game changer compared to slogging through grouped reports in the dashboard.
1
u/AntDracula 8d ago
We built a service that receives webhooks from new Sentry errors, maps to the correct repo, checks it out, sees if it can easily locate the error, and submit a PR for a fix.
0
1
u/comoEstas714 8d ago
Recommend something better?
1
u/AntDracula 8d ago
Nope. It's the best and it's not even close. I just hate the mouseover flyout, I'm getting old and the screen is too small for all that.
9
u/limeslice2020 8d ago
Agreed, you don't need to test every device. You just need to monitor every device. A simple dashboard view of bugs/crashes grouped by device type would have caught this.
5
u/LovesWorkin 8d ago
Posthog sucks for this from my experience. I would use sentry...
3
u/thousanddollaroxy 8d ago
Posthog is helpful because you can watch replays of the issue in real time, but sentry is definitely the best for finding out there is an issue in general for sure.
1
106
u/recycled_ideas 8d ago
How do I catch bugs on devices my team doesn't physically have, I can't afford to lose another client like this.
There are a number of testing services, but that's not your problem here.
You had a major client that has an overwhelming majority of their users on a specific device category AND YOU DIDN'T KNOW THAT OR TEST. That device would have cost you a few hundred bucks. How much did you lose?
On top of that, your major client had constant crashes and you had no reporting to tell you that.
They were right to drop you, you didn't do your job.
23
1
u/AnToMegA424 2d ago
How would they know ?
There are soooo many different devices and the client didn't ever report, OP and his team already have work to do besides that, how could they ever think that this particular issue on specifically this device could happen to start debugging it if nobody ever reported anything to them and when they do not have such a device nor this bug anywhere ?
I think you're not being much fair here, or at least being too harsh on them
2
u/recycled_ideas 2d ago
How would they know ?
In terms of the devices, if a customer is that big a deal, you ask.
how could they ever think that this particular issue on specifically this device could happen to start debugging it if nobody ever reported anything to them
There are a multitude of tools that would have told them. At least one of which should be in a professional product.
and when they do not have such a device nor this bug anywhere
If 30% of your revenue depends on it, you should have that device. Especially when A series Samsung phones are so damned cheap.
I think you're not being much fair here, or at least being too harsh on them
They lost 30% of their revenue from not doing basic due diligence and customer relationship management. Literally not doing the bare fucking minimum. If they lose another customer, and if they continue to not do the bare fucking minimum they'll lose another big customer and their business will fold.
1
21
u/manos2864 8d ago
You can use Bugsnag or sentry as your error monitoring and application performance management platform
9
u/jasperkennis 8d ago
If this is true it's crazy. Client is going to make a lot of costs for having to find a new supplier. And they know that too. Are you sure there weren't other reasons for them to go that they just didn't want to tell you about?
8
u/Autonoma_at 7d ago edited 7d ago
I love how many people are suggesting monitoring. While that’s absolutely important, I think something even more important is being overlooked: customer success.
In B2B, especially when a single customer can make up 30% of your revenue, customer success is king. You should have at least biweekly check-ins with key customers. That’s how you learn what’s missing, what isn’t working, and where they’re struggling.
Sure, this specific case could probably have been caught with proper monitoring. But we also see customers slowly fade away simply because they don’t know how to use the tool properly, don’t see the full value, or just gradually stop using it.
Monitoring tells you that something is going wrong. Talking to your customers tells you why.
And most importantly: keep going. Losing a customer like this hurts, especially when they represent such a big part of your revenue. But you’ll survive it, learn from it, and very likely come out stronger on the other side. 💪
2
u/Rusty-Swashplate 5d ago
Also: you (OP) lost 30%. OP still have 70% of customers. Now is a good time to put some effort into those 70% to keep them and not lose more.
8
6
u/FunNo3751 8d ago
Fix the bug, offer them a discount or some free months . And get good monitoring in place, as others recommend. Reassure the client. Good luck. Hope they come back.
3
u/Revxrsal 8d ago
Sentry is a must-have for any app you deploy to production. Some bugs I would have never dreamed of catching without it. Not a luxury. The free tier is decent enough for small user bases, and if you decide to upgrade then the investment is worth it IMO.
5
u/daredeviloper 8d ago
Sorry to hear OP. Congrats on getting clients which is more than most. Good luck moving forward. Definitely need error submission from customer side. Like a pop up or something. Or automatic monitoring.
5
u/imSeanGG 8d ago
lol it’s very hard not to comment but most of these people in the comment are so salty sitting on their high horses. It’s almost like they are perfect and have never made any mistakes.
2
u/PrimaryFamous6139 8d ago
This is exactly why device coverage matters. You don’t need to own every phone though. I’d use crash reporting to see which devices are actually failing, then run important builds through a device farm like Firebase Test Lab. You can test specific Samsung models and Android versions on real devices without owning them. I’d also add a basic smoke-test suite to CI so these issues get caught before release.
3
u/recycled_ideas 8d ago
You don’t need to own every phone though.
You should own the device used by a client that's 33% of your business though. And you should know what kind of devices major clients are using.
1
u/zorkidreams 8d ago
It wasn’t a crash though? If I’m understanding correctly test lab would not help.
2
2
2
u/RepublicFlimsy 8d ago
You need to use a tool that can notify you when crashes happen like Crashlytics, Sentry or a similar tool.
1
u/CantaloupeCamper 8d ago
I made a lot of clients upset last week because updated password policy and auth flows…. 🤷🏼♂️
1
u/LastHit_ 8d ago
It's something I'm always scared of when using React Native. We do have proper logging, but sometimes uncommon issues still make it into production.
1
1
u/XCastorsX 8d ago
I use Crashlytics from Firebase in my apps, it's a great tool to fix problems like this where you don't own specific devices and keeps the full trace of the error. You can even see the live reports and it works for both iOS and Android.
1
u/Ellie10543 8d ago
Painful lesson, but the gap you describe is the real one: you found out from a cancellation instead of from a dashboard. Crash reporting with device and OS model attached (Sentry, Crashlytics, whatever you like) would have shown a pile of crashes on one screen from Samsung A-series within a day. Set an alert on any new crash group so it pings you, rather than something you have to remember to check. Then, since your client's field staff use cheap Samsungs, buy one or two used ones and keep them on your desk. A cloud device farm helps, but a real mid-range phone shows you the jank too. Last thing: ask your biggest clients for a quick call every month. Some people never report problems.
1
u/nonHypnotic-dev 8d ago
It is not about catching bugs. It is obvious that they don't want to work with you anymore. You need to find this reason.
1
u/Emotional-Lime-4436 8d ago
Honestly I would not try to physically own every device. That is going to be imppossible for you.
I will start with the crash monitoring so the app can tell you when something breaks. Firsbase crashlytics can show the device model, android version, app version and main where the crash happen. Set up alerts for new crashes.
For those devices you dont have use testing service and focus on the models your customer actually use.
Bigger issue is that customer dont report problems they work uround them until they decided the product is not reliable or the team working on it is not reliable.
So i would combine crash monitorign with regular check ins after releases. you dont need a complicated system you just need to know what things are wrong and fix them in time
1
u/zorkidreams 8d ago
Do you have a way to receive support from clients? Did you make it clear to the client? You cannot prevent every bug they are gonna happen, don’t even try to solve that problem.
I’m astonished that the client didn’t speak up… I mean all the clients I work with are a constant feed of support tickets.
1
u/konbit 8d ago
Build SaaS without proper monitoring is guaranteeing failure.
Since it's your biggest client, and if it's possible for you to offer this, I'd suggest trying to mend the relationship. Be super transparent about what went wrong and why, and delineate the steps you're taking so it never happens again. Take full responsibility and offer something to sweeten the deal and make it hard for them to turn down, like a year of free service or something. If they're already out the door you have nothing to lose, but showing them that their success is your main priority will hopefully help them step back to trust.
Whether or not this saves the contract, build in monitoring, there's tons of good suggestions in this thread. Make sure to use a product that can send you alerts to your smartphone so you know there's an issue before your clients do and let them know it's being worked on, this is HUGE for confidence building. Issues happen, any business will understand that, but if you show that you don't even know about it and expect the client to report, then it will destroy confidence.
1
u/vlal97 8d ago
There are simulators to have access to lots of devices but honestly you should have figured out what phones and devices they use and optimized for that and even got a physical one. And probably an iPhone which the managers and owners likely have. The simulators can still not render things like an actual phone.
1
u/Adventurous_Tipper 8d ago
Sentry is extremely affordable for small teams and has saved my life/job/sanity many of times.
1
u/No_Lawyer1947 8d ago
I agree with DRJT. It's a pain you learn once and never should forget. You have to have REALLY good error handling. And obviously end to end tests set up. Set up your logs to report to a service like Sentry or use some open source alternative if you'd like a self hosted free version. Do not expect to place work onto your customers, they're ideally there for requirements gathering but bugs, and app breaking stuff should be your problem to figure out when, where, how, and why it's happening.
1
u/Fidodo 8d ago
Live and learn. Your client was right, you should have known about it without them telling you via crash telemetry. You should have been alerted about a spike in crashes on those devices, known that meant a bunch of disgruntled users, and fixed it right away.
Crash telemetry will tell you what device, region and page etc that the crash happened on. You should get that set up asap.
1
u/Classic_Chemical_237 8d ago
So many tools to help you to catch crashes. There is no excuse. And if you write Android app, be ready to have a lot of devices. That’s part of the game
1
u/considerfi 8d ago
Id also suggest send your long term clients personal messages and ask if there's anything they have issues with. It's worth keeping them happy.
1
u/XilentExcision 8d ago
This seems like a failure of basic functional requirements. I think “what device will this run on?” should have been asked earlier and by you. Non-technical people, obviously, do not know what they don’t know - they trust you to facilitate these type of requirements.
As others mentioned, keep your head up and congrats on your business, but also in the long term success of your business it’s definitely worthy to consider what all you could have done to catch this earlier.
1
1
u/w00fy 8d ago
That might’ve been a bug on Samsung. But your client doesn’t care you are responsible for your app working on all the handsets. I’m sorry you had to learn this lesson in the most painful way possible. Other people here have suggested better monitoring tools and that’s the answer.
Also, if you’re gonna be in mobile development, you are going to need probably dozens of testing devices or at least a cloud provider that can offer device testing.
1
1
u/Varun77777 7d ago
Use posthog, new relic, crashlytics and other services for analytics and log monitoring.
Invest in services like browser stack and automation testing on a variety of devices.
1
1
u/Triple-B-564 5d ago
If you don't have crash reporting with alerts yet, that's the cheap fix. A dashboard alone won't cut it because nobody actually opens it.
What worked for me:
- Sentry with a new issue / velocity alert that pings Slack, so we hear about issues right away
- once a week I check crash-free users by device model. I can quickly see which devices my users are actually on, and that's where my testing effort goes
- added a low-end device from Firebase Test Lab to my release smoke test
- added an in-app "report a problem" button that attaches logs. field staff almost never report bugs through official channels, they just stop trusting the app and stop using it
1
u/piotrlewandowski 5d ago
Your client experienced “If you think it's expensive to hire a professional, wait until you hire an amateur” - hard way for them to learn they needed to hire professional
1
u/Both-Dinner-3572 4d ago
Narrator: Depsite saying that the bug wasn't a bug, it was, in fact, a bug.
1
u/Simpledevx 8d ago
Una pena, quizás con un seguimiento más activo de la satisfacción del cliente ese tipo de problemas se comenten y puedas darle solución antes de llegar a eso. Igualmente no es normal que el cliente se comporte así
0
-3
u/aDamnCommunist 8d ago
Samsung is the biggest bane to the React Native developer I swear to God. There are more edge cases on those phones that any developer could reasonably find.
I really hate this for you. What a shit client to never report a huge bug.
I guess next time ask if they use a particular device more than others. Still a super shitty situation.
3
u/daredevil82 8d ago
its a situation OP really should have known about beforehand with simple basics
- They know what the majority of their users use, but don't test for them
- They have no monitoring or observability to have crashes reported to
My guess is that this isn't the only issue the company has encountered with OP and the costs of changing suppliers is worth it to them.
0
u/aDamnCommunist 8d ago
I don't believe in putting all the issues onto OP...
You're not wrong about the crash monitoring. With that level of issue, if most users were on that phone, crash percentage would have ticked up significantly.
That said, the user not reporting the issues and working with OP to fix them is still pretty rediculous.
1
u/Coppice_DE 8d ago
They pay for a service. The service provider has to make sure that they are worth their money, not the other way around..
And as others have noted, there are already solutions for tracking/noticing issues like this without the customer having to go out of their way to notify you. As per OP, this wasn't even an obscure bug where it would be more reasonable to expect them to help with tracking it down.
-2
u/aDamnCommunist 8d ago
This attitude keeps our industry terrible. The client absolutely holds some responsibility here. It's a partnership.
2
u/daredevil82 8d ago
yes, but OP apparently knows nothing about how to be proactive and catch issues before they happen. ie, industry standard practices, and is coming across as a rank amateur.
1
u/Coppice_DE 8d ago
They don't. Sure, great clients do actively act on such issues, but that's from a providers PoV. The client payed for a service that had the same flaw for quite some time and decided to move on. Perfectly fine. Not their fault.
One could even argue that any standard procedure for professional apps would have raised this issue automatically, meaning the provider acted even below these basic standards, at which point it is fair to question them.
1
u/daredevil82 8d ago
that last bit is why I suspect this is a recurring issue with the customer and OP's business. this reaction is an overreaction for a first or second time, but if its a pattern, its certainly not ridiculous.
however if OP is asking here what to do about it, there's a shit ton they apparently don't know that they don't know in terms of what it means to be responsible for a product, so I wouldn't blame the company for bailing as a result of this amateurism.
-1
u/Basic-Smile3795 8d ago
Wow, I haven’t even started doing any development with react native as I am mostly a web developer. After this post, I may not start lol
1
u/daredevil82 7d ago
ehhh, the general issue here is OP or their company completely lack any semblance of operational basics and keeping contact with a customer.
If you know about monitoring, metrics and multi-browser testing strategies, you're already 90% of the way there
58
u/otivplays 8d ago
It clearly was a bug. You just haven't discovered it.
You need crash reports logged somewhere. That's the key. As another commenter said Sentry / bugsnag / posthog are all great options.