The stack we build on, and what each part is actually for

Ask. The list is what comes up often enough to be worth writing down, not a boundary. Most stacks are variations on the same handful of ideas, and a team that knows one relational database or one component framework well is rarely helpless in front of another. Where something genuinely is outside what we can support responsibly, we will tell you that on the first call rather than learn it on your budget.

No. If you already have a team, an existing codebase or a company standard, the right technology is usually the one your people can maintain after we leave. We will say when we think a choice will cost you later, and then we will build in what you have chosen. The exception is a decision that is genuinely unsafe rather than merely different, and that is rare enough to be worth arguing about properly when it happens.

Working backwards from constraints rather than forwards from preferences. Who maintains it after launch, how easily you can hire for it, whether the job is mostly interface or mostly data, whether anything runs away from a network, and how long it has to keep working. Those answers usually narrow it to two reasonable options, and at that point the difference between them matters far less than picking one and being consistent.

They record how much of our own work sits on a technology, so breadth is never mistaken for equal depth. Core is what we use daily on our own products and client work. Regular is shipped on client projects when the job calls for it. Capable is work we take on, most often to maintain or migrate something that already exists. All three are real. They are not equally deep, and we would rather say so than imply otherwise across a hundred logos.

It depends entirely on whether it is old or unsupported, which are different things. Mature and stable is usually good. Past end of life is a different matter: it means security patches have stopped, app stores may eventually refuse the build, and the pool of people willing to work on it shrinks every year. If you are not sure which side you are on, that is exactly what a software audit answers.

Often that is the best arrangement. We can take a subsystem while your team keeps the rest, pair with them on an unfamiliar part of the stack, or build something and hand it over for them to own. We write the code, documentation and deployment pipeline with that handover assumed, because software your own team cannot maintain is a liability no matter how well it runs today.