Software your team can still maintain in a year.

Most work lands in .NET and C# on the back end, with TypeScript, JavaScript and React on the front, SQL Server, Azure SQL, PostgreSQL or Cosmos DB underneath, and C++ where systems or performance-sensitive work calls for it. The data layer usually deserves more attention than it gets: most applications that become painful to change became that way at the schema, not in the code. The language is rarely the constraint. The harder questions are which integration contract to commit to, what has to be tested, and who maintains it once we are done. If a project is better served by something outside that list, we will say so rather than force a familiar tool onto it.

It does not, but Azure is where our depth is, and we would rather say that plainly than claim neutrality we cannot back. Anything we build is containerized, so if you run on AWS, Google Cloud or your own hardware, you get a Docker image and a deployment you can host yourself. What changes off Azure is our involvement afterward: we can hand over an image and documentation your team runs with, but we would not take on operating an environment we do not know as well as this one.

You do, from the first commit. It lives in your repository, not ours. There is no license to renew and no runtime we control.

Often, yes. We start with a paid assessment: what the code does, what is tested, what the risks are, and what it would cost to make it safe to change. Sometimes the honest recommendation is to leave it alone and build around it.

The Microsoft stack, primarily .NET and TypeScript, on Azure. If your problem is better solved in something else, we will say so rather than force a fit.