Technologies We Work With
Our core stack is .NET and C# with ASP.NET Core. Beyond that, the right technology for a project depends on what it has to do, what it has to connect to, and who maintains it afterwards.
We would rather explain how that decision gets made than list every logo we could put on a page.
What this website runs on
Not a claim — you are looking at it.
- ASP.NET Core MVC on .NET 10
- C# and Razor views
- Bootstrap 5 front end
- Server-rendered HTML
Our core stack
Most of what we build runs on .NET with C# and ASP.NET Core. That is the platform we know deepest, and it is a sensible default for the kind of systems we are usually asked for: business applications with real workflow, real permissions and real integration requirements behind them.
This website is an ASP.NET Core MVC application on .NET 10, using Razor for server-rendered views and Bootstrap 5 on the front end. We mention that not because a company website is an impressive piece of engineering, but because it is the one claim on this page you can verify yourself.
For mobile, we build for Android and iOS — see mobile app development for how that work is scoped, and courier mobile app development for the delivery-specific version of it.
How we choose a technology
Six questions, in roughly this order. Note that none of them is “what is popular this year”.
What does it actually have to do?
A reporting-heavy internal system and a high-traffic public tracking page have different bottlenecks. The requirement decides the architecture, and the architecture narrows the technology.
What must it connect to?
Existing systems constrain the choice more than anything else. If something must talk to software you already run, that integration path is a requirement, not a preference.
Who maintains it afterwards?
A stack your team cannot hire for or support is a liability, however good it looks at handover. This question rules out more options than any technical consideration.
Where does it need to scale?
Usually in one specific place — concurrent users, tracking lookups, document volume — not everywhere at once. Designing for uniform scale is how projects get expensive.
Where will it run?
Cloud, your own server, or a mix. This is often decided by policy, existing contracts or where your data is allowed to live, rather than by what the software would prefer.
How long must it last?
Business software is rarely replaced on schedule. A platform with a long support life and a large hiring pool is worth more than a marginal performance gain.
The decisions that matter most
On a typical project the technology questions that take real thought are narrower than people expect. These are the ones that change the shape of the system rather than just the syntax.
How the data is modelled
Getting the model right matters more than which database it sits in. A clean model survives a change of engine; a confused one does not improve because the storage was upgraded.
Where the integration boundaries sit
Which systems talk to which, in which direction, and what happens when one is unavailable. This is usually the largest source of complexity in a business system.
How much runs in the browser
Server-rendered pages are simpler, faster to load and visible to crawlers. Heavy client-side code earns its place on genuinely interactive screens, not on every page by default.
What the mobile app is responsible for
Whether it is a thin client or has to work fully offline changes the build substantially. For delivery work, offline capture is a requirement rather than an enhancement.
What we will tell you honestly
- If off-the-shelf software would serve you better than a custom build, we will say so — we wrote about that in off-the-shelf or custom software.
- If an integration depends on a third party's API being available and permitted, that is a dependency we confirm before quoting, not after.
- If a technology would make the system harder for your team to maintain, we will recommend against it even where we could build it.
- If replacing your existing system wholesale is riskier than integrating with it, we will propose the integration.
Frequently Asked Questions
Not sure what your project needs?
Describe what the system has to do and what it has to connect to. The stack follows from that — and we will explain the reasoning rather than just naming a technology.