Desktop software that holds up in real operations — not just in the browser.
Windows desktop apps, .NET and WPF software, internal tools, line-of-business systems, and legacy modernisation — built in Germany, with a stable stack, clean architecture, a controlled installer and update model, and integration with devices, backend, and your existing IT. Founder-led, from Krefeld.
- .NET · C# · WPF / WinUI · MSIX · MAUI · Azure
- Hardware, device, and ERP integration under one roof
- Based in Krefeld · Germany & EU · GDPR-aware
Why desktop is still the right channel in 2025.
In many companies, the critical system is not the website — it is the application running on every screen from the first shift to the last: order handling, production control, point of sale, workshop tools, design, warehousing, weighing, label printing. For these jobs the browser is often too slow, too loosely connected to the network, too dependent on the internet — and simply too far away from the device. A well-built Windows desktop app is not “old fashioned” here; it is the more honest answer: fast, local, integrated, durable. p24.co plans and builds .NET desktop software so that it is exactly that again: a reliable tool that boots up in the morning and does not fall over by the afternoon.
When desktop is the right choice — typical use cases.
We see six situations where a .NET desktop app is almost always the better fit than “just a web app”. If you recognise yourself in one of them, you are in the right place:
Internal tools for daily power users
Dispatchers, back-office clerks, workshop leads, production planners: people who use the same software eight hours a day. They need keyboard shortcuts, tables, bulk edits, print layouts, and speed — not animated carousels.
Offline and local-first workflows
Workshops, field service, production, logistics, pop-up sites: internet is unstable or not guaranteed. A desktop app keeps working locally, buffers data, and syncs deliberately with the backend — instead of stalling whenever Wi-Fi flinches.
Hardware and device integration
Label printers, scales, barcode scanners, RFID readers, measuring and test equipment, cash drawers, serial/USB interfaces, local drivers. In the browser a constant fight — on a Windows client a solved problem.
Windows line-of-business software
Specialist software for workshops, labs, law firms, practices, surveyors, property management, engineering and CAD offices. Local data, printing, document export, Word/Excel integration — everything an industry actually needs.
Legacy modernisation (Access, VB6, WinForms, Delphi)
You run an application that has grown over the years on Access, VB6, WinForms, Delphi — or “the Excel with macros that everyone depends on”. It still works, but nobody dares to change it. We take it over and bring it into a maintainable .NET state.
Secure local processing of sensitive data
When data cannot live in a cloud SaaS for regulatory or contractual reasons — factory or customer IP, patient data, confidential CAD files — a desktop app with controlled synchronisation is often the only clean option.
Where desktop is, frankly, a better fit than the browser.
Not every application belongs in the browser. These six points keep coming back in our audits — and each one has a clear lever on the desktop side:
The web version is “almost” fast enough
Large tables, drag-and-drop, bulk operations, and keyboard workflows push the browser to its limits. A native WPF/WinUI surface stays fluid even at 50,000 rows, 200 visible columns, and constant switching between mouse and keyboard.
Hardware integration is not negotiable
As soon as local devices are involved — printers, scales, scanners, test gear — the browser becomes a workaround. .NET addresses these devices directly, with clear drivers, clean timeouts, and predictable error behaviour.
Offline operation must not silently break
If work has to continue without a stable connection, a web app is the wrong tool. A desktop app handles local databases, queues, and conflict strategies properly.
Distribution and updates are a solved problem today
Desktop software no longer means “setup.exe on a USB stick”. MSIX, Squirrel/ClickOnce-style update paths, or a custom update channel make rollouts as controlled as a web deploy — including rollback.
Client-side security is achievable
Local data encryption, Windows authentication, Active Directory, smart cards, signed packages, code-signing certificates. With clear rules a desktop app is not less secure than a browser tab — often it is more *controlled*.
An existing .NET/Office stack is an asset, not a burden
If your IT already runs on Windows, AD, Office, Exchange, SQL Server, and .NET, a .NET desktop app is not a foreign body — it fits in: single sign-on, Word/Excel export, Outlook integration, SQL Server, Reporting Services.
.NET stack and architecture — what you actually get.
A p24.co desktop app is not a setup with a database. Every block below is deliberately designed, documented, and handed over:
1. Discovery & architecture sketch
Use cases, workstations, devices, network topology, existing systems (ERP, AD, SQL), regulatory constraints. Output: a compact architecture sketch, a stack justification (WPF vs. WinUI vs. MAUI), an update model — before the first line of code.
2. UI in WPF or WinUI (MVVM, clean structure)
WPF for classic Windows line-of-business software, WinUI 3 for modern, fluid surfaces. MVVM with typed view models, clear bindings, validation, keyboard operation, print layouts. Where it fits: Avalonia or MAUI for cross-platform scenarios.
3. Application logic in modern .NET (C#)
.NET 8/9 + C#, layered cleanly: domain, application, infrastructure, UI. Dependency injection (Microsoft.Extensions.DependencyInjection), structured logging (Serilog), configuration via IConfiguration. No “god forms”, no UI methods touching the database directly.
4. Local data & sync with the backend
Locally: SQLite or LiteDB for an offline cache, SQL Server LocalDB where it pays off, EF Core for data access. Backend: ASP.NET Core Web API, REST or gRPC, JWT/OAuth authentication, deliberate sync with a real conflict strategy.
5. Hardware & device integration
Integration of printers, scales, barcode/RFID scanners, serial/USB devices, measuring equipment. Drivers are isolated in a device layer — the UI stays independent and new devices can be added without rebuilding the app.
6. Installer, update channel & distribution
MSIX packaging with a signed certificate, a controlled update path (a custom engine, Velopack/Squirrel, or Microsoft Store for Business), rollback for bad releases, optional silent install for IT rollouts via Intune/SCCM.
7. Security, auth & secrets handling
Code signing, signed MSIX packages, authentication via Windows login / Active Directory / Entra ID, local encryption of sensitive data (DPAPI, optional additional AES layer), clear separation between user and admin rights.
8. Logging, telemetry & incident detection
Structured logs locally (Serilog), optional anonymous telemetry to a central backend (e.g. Application Insights), crash reports with stack trace and context. You see problems at the workstations — before the hotline rings.
9. Documentation & handover
Architecture document, stack rationale, data model, device/driver list, installer and update guide, developer onboarding. A new engineer is productive in days, not weeks.
Migration & modernisation: legacy becomes maintainable.
Most desktop projects are not greenfield — they are takeovers: Access, VB6, ageing WinForms apps, Delphi software, or Excel solutions that quietly became the main application. We approach this in clear phases — with an honest interim state instead of a big bang.
- 01
Inventory & risk audit
Week 1–2We map the existing application: features, data model, interfaces, devices, user groups, pain points, and the 20% of workflows that actually matter. Output: a compact audit, prioritised migration risks, clear non-goals.
output → Inventory · risk audit - 02
Target architecture & migration plan
Week 2–3We design the target stack (.NET version, WPF vs. WinUI vs. MAUI, local vs. central data, device layer, backend, update model) and a phased migration plan — including fallback paths if individual modules need to migrate later.
output → Target architecture · migration plan - 03
Data model, migration & strangler strategy
Week 3–5We migrate the data model cleanly (often from Access/MDB, SQL Server, Excel, old schemas) and define a strangler strategy: the new app takes over module by module while the legacy app runs in a controlled way alongside.
output → Migration path · data model - 04
Building the first module (desktop MVP)
Week 5–11We build a first real, production-ready module: WPF/WinUI surface, application logic, local data, backend sync, device integration, logging, installer. Weekly demos, early pilot installs on real workstations.
output → First productive module · pilot install - 05
Hardening, code signing & rollout
Week 11–13Performance, stability, failure paths, security hygiene, code signing, MSIX packaging, update channel, IT rollout documentation, training material. One pilot per site or department, then a controlled rollout.
output → Signed release · rollout plan - 06
Operations, maintenance & further modules
From week 13Go-live, telemetry and crash reports active, a defined support process. Then modular evolution: take over more workflows from the legacy app, add new features, retire the old system.
output → Live operation · maintenance setup
What “good” means for a desktop app, in practice.
You don’t recognise a good desktop app by its splash screen — you recognise it by the qualities that hold up after eight hours of shift work. This is the bar:
Starts fast, stays stable
The app becomes usable within seconds, holds up across a full working day, has no creeping memory leaks, and does not crash “just like that” on printing or scanning.
Keyboard-first, no mouse mandate
Every critical workflow can be run from the keyboard: F-keys, sensible shortcuts, tab order, focus indicators. Power users move faster than in the legacy software, not slower.
Resilient offline and on the LAN
The app keeps working when internet or backend drop briefly. Sync conflicts are detected and resolved, not overwritten. Whatever was created locally is not lost.
Device and print integration that holds up
Label printers, scales, scanners, receipt printers are driven consistently. Print layouts are reproducible, labels come out 1:1 as specified — no “the printer just feels different today”.
Updates are a non-event
New versions are signed, distributed, downloaded in the background, and active on the next start. Problems are rollback-able. No user has to “grab a new setup file from the server”.
Maintainable for years
Tests cover business logic, CI builds and signs reproducibly, dependencies stay upgradable. The app lives for five-plus years — not just until the next Windows release.
Security, privacy, and founder accountability.
A desktop app runs on your employees’ machines, often with access to real business and customer data — it is not a toy. p24.co is run by Dimitri Kronich from Krefeld, Germany. You get a technical counterpart with an EU base who actually owns architecture, security, and privacy — instead of delegating them downward.
- 01Founder-level ownership — a direct line to the person who decides architecture and security.
- 02Based in Krefeld · Germany & EU — GDPR-aware delivery, EU backend hosting, clear processing grounds.
- 03Signed installers, a controlled update channel, and local encryption of sensitive data as the default.
- 04Reproducible releases, documented architecture, a real incident and recovery plan.
- 05A handover designed so another team could keep running your desktop software — no lock-in.
Frequently asked questions about desktop app and .NET development.
Why build a desktop app at all when everything can run in the browser?
Because some applications are simply the wrong fit for the browser: long-shift power-user operation, local device integration, offline use, regulatory constraints on local data, print layouts, keyboard-heavy workflows. For those cases a .NET desktop app is often the more stable, faster, and more honest tool today.
Which technologies do you use for desktop software?
Mostly .NET 8/9 with C#, UI in WPF (for classic line-of-business apps) or WinUI 3 (for modern surfaces), MVVM, EF Core, ASP.NET Core for the backend. Cross-platform where needed via Avalonia or .NET MAUI. Local data via SQLite, LiteDB, or SQL Server. Installer typically MSIX with a signed certificate.
What does a custom desktop app or line-of-business application cost?
A seriously built first module of a .NET desktop app usually sits in the mid- to upper five-figure euro range; larger industry solutions or legacy modernisations quickly enter six figures. We make scope, assumptions, and risks transparent — no “fixed price” on top of half-defined requirements.
Can you modernise an existing Access, VB6, WinForms, or Delphi application?
Yes — that is one of our typical cases. We start with an audit of the existing application, document where things stand, name the risks, and design a phased migration — usually following the strangler pattern, so the old app keeps running alongside until it is replaced module by module.
How do you integrate printers, scales, scanners, and other hardware?
Through a dedicated device layer: every device type (label printer, scale, barcode/RFID scanner, serial/USB device) has a clear abstraction with defined behaviour — timeouts, errors, reconnect. The UI stays independent, and new devices or models can be added without rebuilding the application.
How does distribution and updating of the app work?
Usually as a signed MSIX package with a controlled update channel — versions are published centrally, downloaded in the background, and active on the next start. Where it makes sense we integrate with existing IT tooling (Intune, SCCM) or build a lean dedicated update server.
Does the app work offline, and how does it sync with the backend?
Yes. The app uses local storage (SQLite/LiteDB/LocalDB) and keeps working without internet. As soon as the connection returns, a defined sync layer talks to the backend (REST or gRPC) with a real conflict strategy. Work created locally is not lost.
What about privacy, GDPR, and data residency in Germany?
Local data is encrypted via Windows DPAPI and, where required, an additional AES layer. Backend components are hosted in the EU by default (Azure West Europe or equivalent). Personal data is separated cleanly, processing is documented, and the building blocks for data-processing agreements are in place.
Who operates and maintains the desktop app after launch?
On request, we take over operations: monitoring (crash reports, telemetry), updates, security patches, ongoing development. Equally, you can take over with your own team after rollout — we ship documentation and setup so that path stays real.
Related services and topics
Let’s plan your desktop software properly.
Tell us briefly what application you run today, what devices and systems it touches, and what actually hurts in daily operations. You will get an honest, technical view — directly from the founder, without a sales layer and without buzzwords.