Why we stopped being a .NET shop

For most of our history, we were a .NET shop. We still ship a lot of .NET — it's a mature, performant, deeply capable ecosystem and it's the right tool for plenty of enterprise work. But sometime around the third client whose problem genuinely wanted Go and got .NET because that's what we sold, we stopped describing ourselves that way.

The single-stack incentive

Single-stack agencies have a structural conflict of interest with their clients. You are advising on architecture; you also only get paid if the architecture uses the stack you sell. The advice is going to bend. It bends quietly, with reasonable-sounding justifications, but it bends.

A team that only does .NET will find a .NET answer to every problem. So will a team that only does Node, or only does Python. None of them are wrong on purpose. They are wrong on incentive.

What stack-agnostic actually means

It does not mean we know every stack equally well. Nobody does. It means our senior engineers have shipped production systems across multiple stacks and have the judgment to recommend the right one for the problem — including recommending you not hire us, when the right answer is something we don't do.

That last part is the test. An agency willing to say "this should be Elixir and we don't do Elixir" is being honest. An agency that finds a way to make every problem fit their stack is selling, not advising.

How the choice actually gets made

Stack selection is mostly downstream of four things, in roughly this order:

The team you have or will hire matters more than purity. A theoretically better stack you can't staff is worse than a slightly worse stack you can. We talk about hiring market first.

The compliance and data constraints narrow the field fast. Financial-services workloads on certain regional clouds collapse the options to two or three. Healthcare collapses them further. These constraints are non-negotiable; everything else is preference.

The integration surface with what you already have. Rewriting the world for a marginally better runtime is rarely worth it. We optimize for what you can ship next quarter, not for theoretical elegance.

The performance profile — only after the above three. Most enterprise software is bound by I/O, network, and database design, not language choice. Picking Go over Node "for performance" before knowing whether the bottleneck is the language is, ninety percent of the time, premature.

What we still are

We are senior engineers who happen to be very comfortable in .NET, the JVM, Node, Python, and Go, on Azure and AWS and GCP. We have opinions about all of them and we will tell you which one fits your situation.

We are not, anymore, a shop that has one answer.