Every team has a support matrix. Most have never written it down, which means it is whatever the developers happen to test on — recent Chrome on a good laptop — and everything else works by luck.
Write it down, and derive it from your own analytics rather than from general market share. The distribution of browsers, screen sizes and Android versions among your users is specific to your product, and it frequently differs from the national picture in ways that change the answer.
For Indian consumer products, the long tail is longer than teams expect. Older Android versions persist on devices that remain in daily use, and the browsers on them lag the features documentation assumes are universal. A feature that is listed as widely supported may still be missing for a share of your users.
Small screens deserve explicit attention. Design work is usually done on large displays, and layouts that are comfortable there become cramped at the widths common on budget handsets. Testing at the narrowest width you claim to support, on an actual device, catches problems that a resized desktop browser does not.
Progressive enhancement is what makes a broad matrix affordable. If the core function works with basic capabilities and richer versions layer on top, an older browser gets a plainer experience rather than a broken one. Building the rich version first and adding fallbacks afterwards is considerably more work and usually done badly.
Then publish the matrix, at least internally. It tells designers what they can rely on, testers what to cover, and support what to say when someone reports a problem on something outside it. Without it, every such report becomes an open-ended investigation.
