People often ask what we build with, expecting a list of logos. The list matters less than the reasoning behind it. A stack is a set of bets, and the quality of a delivery shop is mostly the quality of those bets over time. Here is the shape of ours and, more usefully, how we decide what earns a place in it.
The principles first
Before any specific tool, four principles filter everything:
- Boring where it counts. For the load-bearing parts - the runtime, the database, the cloud - we prefer mature, well-supported technology over novelty. Excitement is a cost in production.
- One obvious default per job. Having three ways to do logging is worse than having one good way. We standardize so that moving between projects is frictionless.
- Buy the undifferentiated, build the differentiating. Identity, messaging, and observability are solved problems; we adopt rather than invent. The domain is where we spend our originality.
- Optionality through abstraction. We hide infrastructure behind contracts so a future swap is a configuration change, not a rewrite.
The core runtime
The backbone is .NET and C#. It gives us one language across web, services, and tooling, a fast runtime, and an ecosystem that ships improvements every year. On the front end, Blazor lets us stay in C# for interactive UI and share models with the back end, which removes a whole class of duplication.
Cloud, delivery, and messaging
We run on Azure, with infrastructure expressed as code so environments are reproducible rather than hand-tended. Delivery is automated end to end - build, test, and deploy through pipelines - so shipping is routine, not an event. For anything asynchronous, a message bus decouples producers from consumers, which is what lets parts of a system scale and fail independently.
Data and observability
We match the datastore to the shape of the data rather than forcing everything into one engine: relational where relationships and transactions dominate, document or vector stores where they fit better. Observability is not optional - structured logging, distributed tracing, and metrics are wired in from the first commit, because a system you cannot see into is a system you cannot operate.
Tip: The best time to add observability is before you need it. Retrofitting traces during an incident is the worst possible moment to learn your system is opaque.
AI as a first-class capability
AI is now part of the landscape rather than a side experiment. We use it both inside products - assistants, retrieval, automation - and inside our own delivery process. The same principles apply: model access goes through abstractions, tool surfaces are typed and authorized, and everything is observable.
How the landscape evolves
The stack is not frozen. New tools enter through a deliberate path: a documented decision that captures the trade-off, a small real use behind a flag, and a review before it becomes a default. That keeps the landscape current without letting it sprawl, and it means every technology in it can answer the question "why is this here?"
Wrapping up
A tech landscape is a living set of decisions, not a trophy case. Ours optimizes for boring foundations, single obvious defaults, and optionality through abstraction - so teams move fast without re-litigating the basics on every project. The logos will change over the years; the principles are what keep the changes cheap.
Want to see how this stack maps to your project? Start a conversation.
