Why we only build in C# and .NET
Choosing one platform is not a limitation for us. It is the most important engineering decision we have made, and here is the reasoning.
Every so often someone asks why SwartBerg does not build on a wider menu of technologies. The answer is that we made a choice, on purpose, and it has paid for itself many times over: we build in C# and .NET, and nothing else.
Depth compounds
Software skill is not evenly spread across a career. It compounds in the places you return to. Years of working in one ecosystem means knowing which parts of the framework are fast and which only look fast, how the garbage collector will behave under load, and where the security footguns are hidden. That knowledge only accumulates if you stay.
A team that changes stack every year starts over every year. We would rather start ahead.
The platform earns it
C# and .NET are not a niche bet. The platform runs large systems in banking, insurance, government, healthcare and retail, and it has some properties that matter a great deal to anyone building a product meant to last:
- Long-term support. Even-numbered releases are supported for three years, on a predictable schedule, so upgrades can be planned rather than forced.
- Performance. Modern .NET is among the fastest mainstream web platforms, and it keeps getting faster with each release.
- One language, end to end. With ASP.NET Core on the server and Blazor in the browser, the same language, types and tests cover the whole application.
- Mature tooling. First-class debuggers, profilers, analysers and test frameworks, most of them free.
Consistency is a feature
Because everything we build shares the same foundations, each product looks the same under the hood as the one before it: the same architecture, the same patterns, the same way of testing. Anyone who has worked on one SwartBerg codebase can find their way around any other.
It also means our own libraries get used, and improved, everywhere. SwartBerg.Mediator started life inside our own systems before it was published on NuGet, and every product that uses it makes it better.
One stack, one team
The same choice shapes how the company will grow its team. A company that splits across five technology stacks needs people who know all five, and those people are rare and expensive. A company on one stack can hire graduates who know the language and grow them, product by product, into experts.
Everyone works with the same tools, the same patterns and the same libraries. A developer can move from a mobile app to a web platform to a developer library without starting over, and what they learn on one product makes them better on the next. Expertise accumulates in the team instead of being spread thin across it.
What it means for new ideas
Trying a new app idea is cheap when the foundations are already there. Authentication, data access, testing and deployment are solved problems for us, so an experiment can go from idea to something people can use in weeks rather than months, and an idea that does not work out costs us very little. That is what lets a small, self-funded company keep experimenting.
This website is built in C# too.