Our technology stack, and how a stack gets chosen

No, and being dogmatic would be a poor sign. What we prefer is a stack you can support after we have gone, which frequently means matching what you already run rather than what we would choose on a blank page.

Usually not. Newness buys features and costs stability, hiring pool and documentation. For most business systems that is a poor trade — the exception is when a specific new capability genuinely solves your problem.

That is a legitimate constraint and usually a sensible one, particularly if you have people who know it. We will say if we think it is the wrong choice for a specific requirement, and then work within your decision.

Generally yes. A great deal of our work is on estates built by other people in technologies we did not choose, and being able to work in what is there rather than insisting on a rewrite is part of the job.

Standard technologies, code in your repositories, deployment in your accounts, and documentation written for a team that has not met us. Lock-in is a business model, not a technical necessity.

It is checked rather than assumed, particularly where you redistribute software. Copyleft obligations can affect what you are permitted to do commercially, and that is better established at the start.