DMA is reasonable. It‘s not their job to be concerned so much as to block that access completely. Alternative approaches do exist. For example, they may require independent audit of submitted apps if they do not trust regulators and collect small fees to cover operational costs of dealing with audit ecosystem.

Add to this hard digital sovereignty requirements: continuity of service must be guaranteed for decades. All this requires quite a special setup in which commercial entities are rather tolerated than welcomed, but they may still make more sense than a government agency so constrained by budget process that they cannot hire any decent engineer.

it is not, as long as focus is on goals rather than on solutions (applies to everything). Nobody needs a view or a workflow. Everybody has jobs to be done. That is the starting point in process design.

This is the funniest thing about customization of enterprise products. They spent hundreds of years on user research and product development, so chances are high that their standard solution is sufficient for your problem, and you don‘t need anything else. Yet too many people are tripping on the hard problem of enterprise products: the custom fields, which they hardly even need.

„Everyone does that“ is definitely part of decision-making process almost everywhere, but I personally have not seen companies where it’s just a cargo cult rather than a reasonable strategic choice. The obvious benefits are that it’s easier to find implementation partners, the costs are predictable and your users may already know the system, so you won’t have unnecessary friction in your ops.

* assisted coding, not full code generation

Good that you are asked. Did I say anything like that in my comment above?

You dismissed A/B testing as unnecessary. That is sufficient for this judgement. A/B tests mostly run on the happy path scenario of a customer: An A/B test breaks, the company is losing money at light speed.

The loading-related issues overall may eat 0,5-1% of the revenue. It is not something that should be an afterthought.

An user opening a web page is not expecting a full-blown app with multi-second loading times. If that happens, they bounce, and you loose revenue. Web is supposed to have very short time to first content paint and very short time to interactive, the shorter, the better, less than 0.5s is the goal. It can deliver that, if built properly. Many SPAs, bulky JS apps are built this way for developer convenience, not for end users. The only real use case for SPA is when you deal with a lot of local data. A spreadsheet, document or image editor, a diagram tool (but then wasm is probably a better choice).

You may say, you are not building enterprise grade frontend. But if you are small enough, you don’t need SPA either.

Let‘s say you have 5-7 dependencies to load, but 3 of them timed out because your train entered the tunnel. Your app ends up in incorrect state, fails silently and UX degrades unpredictably. This is where the conversion often drops visibly and the reason SSR is now a go-to solution for any marketing website.