We apply technologies not according to fashion, but according to operational reality, lifespan, integration requirements and team capability. What matters is not the buzzword, but whether the system remains cleanly operable, extensible and able to be taken over.
Strong for business logic and multiplatform clients
Delphi is strong where established business logic, database-near processes, reports and stable clients for Windows, macOS and Linux are to be continued over the long term.
view Delphi
C#
Strong for REST, services and portals
We use C# when portals, modern backend services, REST APIs and integrations need to connect cleanly to existing enterprise systems.
view C#
Architektur
Layer-3 instead of monolithic legacy
We deliberately separate presentation, business logic and data access so that changes remain plannable and new services do not have to be built against the existing system.
view Layer-3
Plattformen
Take Windows 11 ARM64 into account from the outset
In addition to classic x64 targets we consider current platforms such as Windows 11 ARM64 early, so that new hardware and deployments do not later become special projects.
view ARM64
When each approach makes sense
Delphi is appropriate when
- existing domain logic should continue,
- complex desktop processes need to remain stable,
- Windows-, macOS- and Linux-clients are to be developed on a shared functional basis.
C# is appropriate when
- REST servers and services are being established,
- APIs and external integrations are the focus,
- modern service architectures are required.
Hybrid is appropriate when
- existing applications and new portals must work together,
- desktop, services and web share the same data foundation,
- modernization should proceed incrementally and as a Layer-3 structure.
Delphi modernization in practice
When an old Delphi application still retains domain value, we do not modernize blindly. We first analyze how the system actually operates, which processes it supports, where data flows break and which legacy burdens slow down operation. From that we derive a modernization path that not only looks clean on paper but remains viable in everyday operation.
In many mature applications, the real value does not lie in the UI, but in years of domain logic, special rules, exceptions and experiential knowledge. This substance is not discarded lightly. We separate responsibilities cleanly, reorganize the database, replace old access paths, create new REST interfaces and, if necessary, add clients for Windows, macOS and Linux on the same functional basis. This does not create a hard break, but a comprehensible evolution with a clear technical delineation.
Often this also means bringing historically grown monoliths back into a form that is maintainable, testable and extensible. Data access is stabilized, business logic is extracted from UI code, interfaces become plannable and future extensions no longer have to be fought against the existing system. The goal is not cosmetic modernization, but a system that gives the company room again for new requirements.
Services and servers as part of the same architecture
Many enterprise systems today need not only a client, but also background services, Windows- or Linux-services and REST servers. That is precisely why we do not plan these parts as an add-on, but as part of the same architecture. A service that is added later as an afterthought almost always becomes an exception case.
If data is to be processed in a distributed fashion, interfaces provided, exports executed, imports monitored or scheduled tasks run in the background, technical responsibility must be clarified from the outset. Which parts run in the client, which in the service, which on the server, how are errors made visible, how are state changes traceable, how does the domain logic remain consistent? We answer these questions early so that individual components become a robust overall system.
This is especially critical in multiplatform projects. A desktop client on Windows, macOS or Linux must not mean something different in domain terms than an accompanying REST server or a background service. That is why we always design data models, processes, permissions, integrations and operations together. This results in an architecture in which clients, services and servers speak the same language.
Our principle
Technology is not a belief system for us. What matters is that architecture, team capability, operations and future extensions fit the company. The loudest platform does not win; the one that allows risk, maintainability and growth to be managed sensibly does.
We deliberately solve some tasks with Delphi, because there established business logic, high-performance clients and multiplatform capability can play to their strengths. Other requirements are better suited to C#, to services, to a portal or to a combination of both. Good architecture does not arise from fashion, but from clarity: which component has which responsibility, what lifespan is to be expected, how large is the team, how critical is operations and which extensions are realistically likely in the coming years?
This is where professional software development begins for us. We do not just want to deliver something that works today, but to create a technical foundation that remains traceable, transferable and economically maintainable later on.
Frequently asked questions about technology and architecture
Technological decisions must fit the team, the domain and operations. That is why we do not address these questions abstractly, but always in the context of the concrete system.
When is Delphi a sensible alternative to a full new platform?
Whenever evolved domain logic, high-performance desktop processes and multi-platform objectives should be carried forward economically, rather than needlessly replacing core assets.
When do you additionally deploy C#?
Primarily for portals, web backends, REST services, integrations and service-oriented architectural components that integrate well with existing desktop systems.
How important is Layer-3 in practice?
Very. Only the clean separation of UI, business logic and data access makes modernization, testing, services and future platform migrations manageable.
Do you consider new platforms like Windows 11 ARM64 early on?
Yes. New target hardware and deployment paths are evaluated early so they do not become costly special projects later.
Read additional questions in one place
These short answers remain on this page. On the central FAQ landing page we additionally contextualize the topic with regard to architecture, modernization, platforms and operations.