React apps your team enjoys using

Vue for anything living inside or next to Shopware, since the Shopware administration is Vue and one mental model is worth a lot. React for standalone portals, dashboards and customer back offices, where the ecosystem is bigger.

Often yes, and usually what you actually need is 'scan and queue' — a well-built web app handles that and syncs when the WiFi returns, without a native app and an app store review.

You do, from the first commit, in your Git repository, with documentation that lets another team take over.

No, and we will say so. A form, a table and a submit button are a server-rendered page with almost no build tooling — cheaper to build and still running untouched in five years. React earns its keep once the screen has real interactive state: live filters, drag and drop, a dashboard that updates while you are looking at it.

The visible part is rarely the expensive part. Charts, tables and filters are a few weeks of work; what drives the number is where the data comes from and how clean it is. A dashboard over one tidy database is small. The same dashboard over three systems that disagree with each other is an integration project with a chart on top.

Only if someone touches it now and then. A front end left completely alone for three years usually needs a day or two of dependency work before it compiles again — that is the honest cost of the JavaScript ecosystem. We keep the dependency list short and boring for exactly this reason, and would rather write forty lines ourselves than add a package that ages badly.

It can be, if the content only exists after JavaScript has run. For an internal tool nobody should be indexing anyway, it does not matter at all. For a customer portal or anything public, we render on the server so the page arrives as HTML — crawlers and AI answer engines read what is in the response, not what your bundle produces later.