Brief
You describe the users, the job to be done, current tools and any hard date or constraint. A page is enough.
Services
Desktop software for rooms where a browser tab is not the product
Some work still belongs on a desk, a counter or a warehouse PC: hardware, local printers, offline hours, or staff who must not lose a session when the connection drops. Hirvex Technologies builds desktop applications and the services behind them, including .NET where Windows is the real environment.
Who this is for. Operations that run on Windows floors, shared terminals, or mixed online/offline sites.
Problems we typically meet
These are the patterns that show up before a useful first release—not abstract “digital transformation” language.
- A web app was forced onto a counter and fights printers, scanners or cash drawers.
- Legacy desktop software cannot be staffed or extended.
- The site must keep selling or recording work during an outage.
- IT needs an installer, auto-update and a known system requirement—not another URL.
How we approach the work
We document devices, OS versions and the worst network the app will see. Then we choose .NET, a wrapped web client, or a mixed model. Installers, updates and logging are part of the product. If a browser-based client is genuinely enough, we will recommend that instead of manufacturing a desktop project.
What a serious first release can include
Scope is confirmed in discovery. This is the shape of work we are equipped to deliver—not a menu you must buy in full.
- Windows desktop applications with .NET
- Local device integrations (printers, scanners, payment terminals where APIs exist)
- Offline-first data with later synchronisation
- Role-based screens for shared PCs
- Packaging, updates and basic endpoint logging
- Companion cloud APIs and admin consoles
What we need from you
A useful brief is better than a long one. If you can answer most of the following, we can propose a first slice instead of a theatre estimate.
- Who will use this, and what must they finish in a session?
- Which systems must stay (accounting, payments, identity, a shop)?
- What is already live that we should not break?
- Any hosting region, language or compliance rule that is non-negotiable?
- The date that actually matters—and why.
How an engagement runs
Four steps. No mystery bench.
Scope
We reply with clarifying questions and a first-release outline: modules, roles, integrations and what “done” means.
Build
Named engineers work in visible increments, with staging you can click and a weekly written status.
Run
Launch, handover and a support path. The system is yours to operate—not a black box we disappear from.
Questions we are asked
Should this be desktop or web?
If the work is hardware-heavy, offline-heavy or runs on locked-down PCs, desktop is often honest. If staff already live in Chrome and the network is stable, web is usually cheaper to evolve. We decide with you, in writing.
Do you still support Windows applications?
Yes. .NET remains a core backend and desktop option in our stack for that reason.
Can you replace a legacy desktop system gradually?
Often. We wrap, integrate or migrate module by module so the floor does not stop on cutover day.
Start a conversation
If this is the work in front of you
Send the users, the job to be done and any hard constraint. We will answer as engineers—not with a canned brochure.