We select technologies not by trend but by operational reality, lifespan, integration requirements and team capability. What matters is not the buzzword, but whether the system remains cleanly operable, extensible and transferable.
Well-suited for business logic and multi-platform clients
Delphi is strong where established business logic, database-centric processes, reports and stable clients for Windows, macOS and Linux need to be maintained long-term.
View Delphi
C#
Well-suited for REST, services and portals
We apply C# when portals, modern backend services, REST APIs and integrations need to connect cleanly to existing enterprise systems.
View C#
Architecture
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
Platforms
Include Windows 11 ARM64 from the start
Alongside classic x64 targets we take current platforms such as Windows 11 ARM64 into account early, so new hardware and deployments do not become special projects later.
View ARM64
When each direction is appropriate
Delphi is appropriate when
- existing business logic should be preserved,
- complex desktop processes must remain stable,
- Windows-, macOS- and Linux-clients should be built on a common business basis.
C# is appropriate when
- REST servers and services are to be built,
- APIs and external integrations are central,
- modern service architectures are required.
Hybrid is appropriate when
- existing applications and new portals must work together,
- desktop, services and web use the same data foundation,
- modernization should proceed incrementally and as a Layer-3 structure.
Delphi modernization in practice
If an old Delphi application still has functional 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 artifacts slow down operations. From this we develop a modernization path that not only looks clean on paper but remains viable in daily operation.
In many established applications the real value does not lie in the user interface but in years of business logic, special rules, exceptions and experiential knowledge. That substance is not discarded lightly. We separate responsibilities cleanly, reorganize the database, replace old access paths, create new REST interfaces and, where necessary, add clients for Windows, macOS and Linux on the same functional basis. This does not create a hard break but a traceable evolution with a clear technical profile.
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 separated 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 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 afterthought but as part of the same architecture. A service that is added later in an ad-hoc way almost always becomes a special case.
If data is to be processed in a distributed manner, interfaces provided, exports run, imports monitored or tasks executed on a schedule 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 is the business logic kept consistent? We answer these questions early so that individual components form a robust overall system.
This is especially critical in multiplatform projects. A desktop client on Windows, macOS or Linux must not mean something different functionally than an accompanying REST server or a background service. Therefore we always consider data model, processes, permissions, integrations and operations together. This produces 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 platform that allows risk, maintainability and growth to be sensibly controlled 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 these. Good architecture does not arise from fashion but from clarity: which system part holds which responsibility, what lifetime is to be expected, how large is the team, how critical is the operation and which extensions are realistically likely in the coming years?
For us professional software development begins precisely there. We do not just want to deliver something that works today, but to create a technical foundation that remains understandable, transferable and economically maintainable later on.
Frequently asked questions about technology and architecture
Technological decisions must fit the team, the business domain and the operation. That is why we do not address these questions abstractly, but always in the context of the specific system.
When is Delphi preferable to a complete new platform?
Whenever existing business logic, high-performance desktop processes and multiplatform objectives should be carried forward economically, instead of needlessly replacing core assets.
When do you additionally employ C#?
Primarily for portals, web backends, REST-services, integrations and service-oriented architecture components that can be well integrated with existing desktop systems.
How important is Layer-3 in practice?
Very. Only a 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 examined early to prevent them from becoming costly special projects later.
Read more questions in one place
These short answers remain on this page. On the central FAQ landing page we also position the topic in the context of architecture, modernization, platforms and operations.