| Many commentors have given you advice at higher level. On a tactical level, First work with your development team on setting up temporary stores(autosaves) workflows either at the browser/ app level and/or in the backend with redis/Kafka etc. If your users can think they can safely refresh and un submitted forms would be there , then they won't worry that much. Secondly from a devops point of view, there is a lot of things you can do improve tooling for your teams. Canarying deployments, CI/CD automation, performance monitoring (APM) robust traceability and observablity, better error tracking and deeper data captures(session /request replays), to help solve bugs faster, production like environments with good mock data, failure point simulations with network etc, isolated dev environments (virtual clusters) . Ability to run code in a PR etc. [1] The idea is you catch bugs before it goes to users or before the user notices. ---- From a biz perspective your boss will not change his view, even with some bugs you are better than the market and decision makers in companies buy a product for features, not because it is bug free , they don't care because the buyer is not the user. Your boss will only start caring if you start losing customers over bugs. There is no right answer, many times your boss is right, sometimes not fixing bugs can explode technical debt and slow your growth or kill the product too, very hard to know that balance. --- [1] these are things devops could do without product engg involvement for the most part, writing units tests or fixing architecture is not a practical initiative for you to take up although it may pay off more . |