You need a desktop application that works under real conditions: offline on the shop floor, with direct hardware access, on a panel PC that has been running for five years. We develop desktop software that does exactly that.
We develop desktop applications for demanding industrial environments where hardware access, offline operation and performance are decisive.
For us, desktop is not a fallback for cases where a web app is not an option, but a deliberate platform decision. It pays off wherever an application is deeply embedded in existing systems, processes large volumes of data or runs under conditions that a browser cannot reliably cover.
We develop desktop applications at WPF/.NET production level for Windows, complemented by cross-platform solutions with Avalonia, MAUI, Electron and Tauri. Our clients in desktop application development come predominantly from industrial settings, for example mechanical engineering, agricultural technology, medical technology or the energy sector. What our clients have in common is complex requirements and often a legacy IT landscape. As an experienced desktop development company, we are set up for exactly this complexity.
Tell us about your plans. In an initial conversation, we find out together whether desktop is the right path for you.
The agile mindset of everyone on the slashwhy project team is impressive and positively contagious. We work with slashwhy as equals in agile project teams and reach our goals more quickly together.
Markus Rose
Director CHARX control Division Charging Infrastructure at Phoenix Contact
The major benefit of the solution developed with slashwhy is that we can run the further development of the series products in parallel with the new development projects.
Axel Schröder
Director Advanced Engineering at CLAAS E-Systems
We always feel that slashwhy takes full ownership of the product. Everyone involved fully identifies with the product. This is different from other service providers.
Dr. Melanie Schuh
Product Management at W&H
We found a partner in slashwhy who doesn’t just deliver code but supports the entire process from conception to implementation, truly identifying with the product and actively improving it.
Friedrich Laube
Director Digital Products & Services Smart Home at Miele
The question of whether a solution is better implemented as a desktop, web or mobile application follows concrete technical criteria. Our recommendation always starts with this question, not with the technology.
If one of the following conditions applies, we recommend desktop. If none applies, we openly advise the alternative, whether web development, mobile development or a hybrid architecture. For us, this assessment is part of the project start.
Desktop development is the right choice in these cases:
Protocols such as RS-232/485, USB-HID, CAN bus, OPC UA or GigE Vision can only be addressed to a limited extent through browser APIs. A native desktop application communicates directly with the hardware, without detours and without a sandbox.
Some applications have to work fully offline. Not in the sense of a service worker with limited IndexedDB storage, but with full local functionality without network dependency: data storage, business logic, visualization.
Direct database access, COM interop with Office or CAD applications, P/Invoke on native DLLs: these requirements arise in legacy IT landscapes and can be addressed cleanly with a native application.
Thousands of data points per second, DirectX-accelerated rendering, large file operations: these are requirements where browser runtime environments have structural disadvantages. WPF uses the GPU directly via DirectX and comes with high-performance rendering and custom drawing pipelines out of the box, without additional graphics libraries.
A desktop application in industry often accompanies a machine fleet for years, sometimes decades. That is why we don't develop for the moment of delivery, but for a lifecycle in which requirements change.
Dr. Joachim Wilharm
Managing Director at slashwhy
Which technology is right for a desktop project depends on the specific requirements, not on our preferences. We approach every project with an open mind on technology and make the technology decision together with the client, based on requirements, lifecycle expectations and existing system landscapes.
For Windows application development, WPF on .NET 10 is our standard. The framework has been active since 2006, open source since .NET Core 3.0, and offers full backward compatibility. For industrial applications with lifecycles of ten to twenty years, this is not a detail but a central selection criterion. We apply MVVM consistently, work with custom controls, rendering pipelines and dependency injection, and use EF Core with SQLite or SQL Server for local data storage.
In addition to Windows, we also develop for macOS and Linux when needed. Linux plays a role above all in manufacturing automation, for example on panel PCs with a Linux image. We cover macOS and mobile target platforms through cross-platform frameworks. For cross-platform requirements, we rely on Avalonia, MAUI, Electron and Tauri. The decision between cross-platform and a native Windows stack depends on whether deep OS-specific APIs such as COM interop or WDM driver interfaces are necessary and what performance requirements apply to rendering. If they do, we recommend WPF. If not, cross-platform frameworks can reduce the effort considerably.
We advise against certain technologies, however: WinForms has no native binding system and does not support MVVM. UWP was abandoned by Microsoft in favor of WinUI 3. WPF on .NET Framework 4.x no longer receives feature support. Anyone developing or modernizing today should choose .NET 8 or newer.
Languages and frameworks: C#, .NET 8 or newer, WPF, Avalonia, MAUI, Electron, Tauri
UI and architecture: XAML, MVVM, dependency injection, custom controls
Data and persistence: EF Core, SQLite, SQL Server Express, LocalDB
Interfaces: REST, SOAP, ODBC/OLEDB, OPC UA, MQTT, SignalR
Cloud connectivity: Azure IoT Hub, Azure Service Bus
Hardware and peripherals: System.IO.Ports, VISA/GPIB, manufacturer-specific SDKs (e.g. Basler Pylon)
Deployment: MSIX, WiX
WPF stands for Windows Presentation Foundation. Microsoft introduced it in 2006 with .NET Framework 3.0, released it as open source under .NET Core 3.0 in 2019 and has been actively developing it ever since. Rendering runs via DirectX, hardware-accelerated, vector-based and resolution-independent.
What sets WPF apart technically: the user interface is described declaratively via XAML, which consistently separates presentation and logic. The MVVM pattern, implemented with INotifyPropertyChanged, ObservableCollection and ICommand, makes applications testable and maintainable in the long term. Dependency properties enable binding, animation and styling across the entire visual tree. Control templates allow the complete visual redefinition of individual components, the basis for consistent white-label theming in industrial applications.
Typical areas of use are machine configurators, HMI-style visualization and SCADA clients, measurement and test bench software, ERP and CRM clients as well as reporting tools and CAD viewers. Wherever performance, longevity and deep hardware access allow no compromise, WPF plays to its strengths.
Why WPF remains attractive for industrial clients compared to web alternatives:
Longevity: Web stacks have lifecycles of months to a few years. WPF has been running for almost twenty years with full backward compatibility, while web technologies such as AngularJS have been discontinued or, like Create React App, deprecated. For applications intended to outlast a machine lifecycle, API stability is an important criterion.
Hardware without a sandbox: Access to hardware peripherals happens directly via LibraryImport, CsWin32, System.IO.Ports or Windows.Devices.Enumeration, without browser consent and without the restrictions of a web sandbox. The same applies to Office interop: COM access to Excel, Word or Access objects works natively and without detours.
Performance: WPF renders via the GPU (via DirectX) and comes with tools for data-intensive interfaces out of the box: VirtualizingStackPanel with recycling mode for tables with 100,000+ rows, DrawingVisual for composition without layout overhead, WriteableBitmap for pixel-direct display of signal plots. Since no browser engine runs alongside, a WPF application also often gets by with less memory than a comparable web counterpart.
Mature control ecosystem: Libraries such as DevExpress, Telerik and Syncfusion provide Gantt charts, pivot tables, real-time charting and CAD canvas at a performance level that surpasses web counterparts.
Controlled runtime environment: No browser version conflict. The execution environment is fully defined by the installation package.
Desktop applications rarely stand alone. They communicate with local databases, ERP systems, cloud backends and hardware peripherals. In desktop projects, this integration is often the real challenge, not the application itself.
For local data storage we use SQLite via EF Core for zero-administration scenarios, and SQL Server Express or LocalDB for multi-user operation and larger volumes of data. We connect ERP and CRM systems via custom REST and SOAP interfaces, and for legacy systems also via direct ODBC/OLEDB access.
For cloud integration we use Azure IoT Hub for device-to-cloud telemetry, Azure Service Bus for message-based backend integration and SignalR for real-time push from the server. We connect hardware peripherals via OPC UA, MQTT, VISA/GPIB for measurement technology and manufacturer-specific SDKs such as Basler Pylon for industrial cameras.
An architectural pattern we frequently use in industrial projects is the offline-first hybrid architecture: the application works fully locally with robust data persistence and synchronizes seamlessly with the cloud backend as soon as a connection is available. This is not a compromise between offline and cloud, but a considered architectural decision for environments where network availability cannot be guaranteed.
Many desktop applications in industrial settings have a long lifecycle behind them. At some point comes the moment when the technology is no longer maintainable, support runs out or new requirements can no longer be implemented with the existing stack. That is when clients come to us with modernization projects.
Code-behind monoliths without MVVM, without test coverage, with direct database access from UI events. The goal is a clean architecture that can be developed further.
Win32 applications with the msvbvm60.dll runtime and COM interop to Office components. The transition requires careful inventorying of all native dependencies.
Business logic embedded in Access or Excel, transferred into a standalone, testable application.
Common with long-lived industrial applications where the maintainability of the existing codebase is no longer assured.
The pitfalls are incompatible NuGet packages and WCF dependencies that must be migrated to CoreWCF or gRPC.
The greatest technical risks in modernization projects are undocumented business logic, missing test coverage and complex COM interop dependencies. Our approach: code archaeology and power-user interviews for the business logic, characterization tests on the legacy system as a safety net, a complete inventory of all native dependencies before the first migration step. We treat data migration as a separate project element with validation rules, a rollback strategy and parallel operation of both systems.
A large share of our desktop projects comes from mechanical engineering, agricultural technology, the energy sector and other manufacturing industries. Machine configurators with rule-based validation logic, HMI-style visualization of machine status and sensor data, real-time dashboards for test benches: these requirements do not surprise us in the briefing.
What this means in concrete terms: we know that no stable Wi-Fi is to be expected on the shop floor. We know that the application is operated with gloves and has to run 24/7 without a restart. We know that OPC UA, Modbus TCP and PLC connectivity are not exotic requirements but standard tasks in an industrial context. And we understand that dual control, audit trail and role concept are not feature wishes but compliance requirements that belong in the architecture from the outset.
In medical technology, requirements such as device control in accordance with IEC 62304 or FDA 21 CFR Part 11 are added. Concepts such as recipe management, SPC or production orders are familiar to us from mechanical engineering. This saves project time and prevents the expensive misunderstandings that arise when a development partner has to acquire the necessary domain knowledge only during the running project.
Where desktop applications communicate directly with embedded systems, for example when connecting controllers or sensors, we work closely with our embedded experts.
Desktop applications are in demand above all in industry, but our experience does not end there. We develop for a range of industries and transfer solution approaches from one field to the next. Insights from manufacturing thus flow into projects in the energy sector, agricultural technology or medical technology, and vice versa.
Especially in complex desktop projects, our agile development process with regular exchange, short cycles and continuous user feedback is the most effective protection against costly wrong developments.
Henning Möller
Agile Travel Guide at slashwhy
The real challenge rarely lies in the individual application, but in its interplay with legacy systems. For us, complexity is not an exception but the norm we are set up for, especially in an industrial context.
Dr. Joachim Wilharm
Managing Director at slashwhy
A joint workshop at the start of a desktop project, such as a user story mapping session, creates clarity in a short time for everyone involved about the shared product vision and the scope of the solution, and enables a prioritization of the requirements that create the greatest value. At the same time, possible gaps in the original requirements can be uncovered and closed early.
Henning Möller
Agile Travel Guide at slashwhy
Our approach
How does a desktop project work at slashwhy? The following overview shows this, from the first requirement to ongoing development. It is explicitly not a rigid phase model based on stage-gate logic. We develop according to Scrum: iterative, empirical and in close coordination with you as the client. Requirements, design and development grow together rather than being worked through strictly one after another. The five sections should therefore be understood as focal points over the course of the project, not as a rigid sequence.
At the start, we clarify together with you what your application has to do. In workshops, we capture the usage context, technical conditions and the integration requirements for machines and existing systems. In doing so, we think from the real workplace and the people who will later work with it in practice, not from theoretical assumptions. That is why we involve real users early, because a desktop application that later cannot be operated in its actual working environment helps no one. Exactly how this looks is something we tailor to your project context. We define initial architecture principles and the technology choice early enough to give the project direction, and refine them based on insights from development. On this basis, an initial estimate and a prioritized backlog emerge as the foundation for the roadmap. This estimate is a starting value that sharpens over the course of the project, not a one-off figure at the beginning: you decide on budget and scope in an informed way at all times.
As soon as the shared picture of the requirements is in place, we prepare the project start. We set up the technical infrastructure: repositories, CI pipeline and the build environment for your target platform. In parallel, initial operating concepts and prototypes take shape in Figma, where design can be reviewed early and inexpensively. In an industrial setting in particular, the real working environment and the concrete usage scenario matter here: can the application be operated with gloves and read under changing light? Can the font size be adjusted, does touch operation work when no mouse is available? We clarify such questions about the deployment context and accessibility on the prototype, while changes are still easy to make. For us, UX & UI Design is not an upstream discipline that would be finished with the prototype. Design and development work together in the same team, throughout the entire project.
Development itself follows Scrum. In sprints of typically three to four weeks, a runnable increment emerges regularly. We don't create such an increment to tick off progress, but to make it verifiable: it is the basis on which we jointly assess whether we are on the right track, and from which we adjust the backlog and roadmap over the course of the project. Technically, we rely on a sound architecture: MVVM applied consistently, automated tests from the start and traceably documented architecture decisions. Undocumented business logic in the code-behind has no place with us. Usability tests with real users run in parallel with development, not as a final check. This way, you make your decisions in an informed way at all times: after each sprint, you see where the project stands and decide with us what will be implemented next.
Before delivery, we make sure the application works reliably on the actual target hardware. System integration and performance tests on the target devices already run during development, not only at the end. For desktop software, the rollout itself is more than a copy operation: we plan installer, upgrade scenarios and the migration of existing data from the outset, especially when many workplaces or machines are affected. This way, delivery meets an application that has already been proven under real conditions.
With delivery, a desktop project is rarely at its end. New hardware is added, operating systems are updated, connected machines and systems change, and new requirements arise from daily use. We know your application and its deployment context and therefore continue to support it after the rollout as a reliable development partner. So that your knowledge does not depend on individual people, architecture documentation and development guidelines are created continuously on our side. This keeps the application maintainable and ready to hand over, even if the team changes or another service provider takes over further development.
You know what you need, or you are not yet sure whether desktop is the right decision. Either is a good starting point for an initial conversation.
MSIX and WiX sound like a minor issue. In practice they mean: upgrade scenarios with database migration, silent install for SCCM/Intune rollouts, corporate proxy handling and dependency management for the .NET runtime, VC++ redistributables and drivers. A poorly considered deployment is one of the most common causes of problems after the first release.
Anyone used to deploying databases centrally underestimates what it means to carry out schema migrations on distributed local instances. Every application with a local database needs a well-considered migration strategy, a rollback option and a DB backup before every schema transition.
Desktop applications are developed on high-end workstations and operated on five-year-old panel PCs with 4 GB of RAM. Performance tests on the actual target hardware are mandatory, not an optional step at the end of the project.
Windows application development refers to the development of native software that runs directly on the Windows operating system, without a browser or app store. Typical technologies are WPF, WinForms and WinUI for the interface, and .NET as the runtime and development platform. Windows applications have direct access to hardware, local file systems and OS interfaces and are especially common in industrial environments, where offline operation, hardware integration and long lifecycles are central requirements.
A desktop application runs as a native process directly on the operating system, without a browser. It has direct access to hardware, local file systems and OS interfaces and works fully offline. A web app runs in the browser, is accessible independently of the platform and is easier to deploy, but has no direct hardware access and depends on a network connection. The choice depends on the specific requirements: hardware integration, offline capability and performance speak for desktop; easy accessibility and central data storage rather for web.
Neither option is better across the board; it depends on the requirements. Native desktop development means developing an application specifically for one operating system, on Windows typically with WPF and .NET. This enables full access to operating-system-specific APIs, hardware peripherals and maximum rendering performance. Cross-platform development with frameworks such as Avalonia, MAUI, Electron or Tauri makes it possible to use a shared codebase for several operating systems. This reduces the effort when an application is to run on Windows, macOS and Linux, but reaches its limits with deep OS integration or high performance requirements. The right choice depends on the target platforms, the technical requirements and the expected lifecycle.
WPF is suitable when deep Windows integration is necessary: hardware peripherals at the protocol level, high-performance custom rendering, COM interop with legacy systems or lifetimes of ten to twenty years. Electron is a good choice when cross-platform availability is important, web technologies are available in the team and no deep OS-specific APIs are needed. The disadvantage of Electron: every application brings its own browser runtime, which is reflected in resource consumption and start-up times.
Yes. Existing desktop applications can usually be modernized, even if they are based on outdated technologies such as WinForms, VB6, Delphi or VBA. The first step is a careful assessment: what business logic is in the code, what native dependencies exist, where are the greatest risks? On this basis, it can be decided whether a gradual migration or a rebuild is the more sensible investment. Typical modernization paths lead from WinForms or VB6 to WPF on .NET 8 or newer.
The cost depends heavily on complexity, integration requirements and the desired UX quality. Simple internal tools differ considerably from industrial applications with hardware integration, offline capability and complex data models. A reliable estimate usually emerges after a joint requirements analysis in which the development team assesses the backlog.
Relevant criteria are industry experience, technological depth and the ability to make the right platform decision. A service provider that offers desktop only as a standard solution, without examining web or mobile as an alternative, is not a reliable advisor. Equally important is experience with system integration, that is, the connection to ERP systems, hardware peripherals and cloud backends, because the real complexity often lies not in the application itself but in its embedding into existing IT landscapes. Reference projects from similar requirement contexts and traceable architecture decisions are good indicators of delivery competence.
Whether a technical detail question, an assessment of the platform choice or a first project idea: feel free to get in touch with us, with no obligation. We share our experience from many desktop projects and help you find the right path.
Whether an internal specialist application, control software or a data-intensive analytics application: we develop tailored desktop applications that are designed around the concrete tasks and needs of your business. Unlike standard application software, this is how individual software solutions emerge along your processes, not the other way around.
In building them, we rely on established programming languages and frameworks from the .NET ecosystem. Which technology we use for programming depends on the requirements: on the target platforms Windows, macOS and Linux, on the desired efficiency in operation and on whether the solution needs to be scalable in the long term. For applications that grow beyond pure desktop use, we combine desktop and web applications into hybrid architectures, in which you continue to benefit from the advantages of a desktop application such as direct hardware access, offline capability and high performance.
From the initial analysis through the development of the user interface to deployment, you are accompanied by a team that knows the technical challenges of industrial software development. An agile way of working based on Scrum, transparent communication and an eye for local data storage, data protection and business continuity ensure that in the end a software solution stands that reflects the actual needs of users and reliably supports them in their daily work.
