Questions and Answers
Central FAQs at a glance
FAQ landing page
Central questions and answers about specialist software, Delphi, architecture, portals, services, and modernization.
This page collects the most frequent questions from our specialist subpages in one place. The compact FAQs deliberately remain on the respective detail pages. Here we additionally arrange them as a landing page so that interested parties can quickly see which topics we truly master in Delphi, C#, Layer-3, portals, modernization, data access and platform strategy.
You can either jump directly to a topic block or switch to the corresponding detailed subpage from below. This makes the page usable both as a quick entry point and as a structured FAQ hub.
Specialist software
Custom specialist software & Layer-3
Questions about cost-effectiveness, process logic, roles, data and long-term extensibility.
Directly to the answers
Performance
Multiplatform with Delphi
Questions about Windows, macOS, Linux as well as later iOS and Android paths from a shared business logic.
Directly to the answers
Performance
Services, REST servers & portals
Questions about portals, APIs, Windows and Linux services as part of the same application architecture.
Directly to the answers
Integration
Interfaces, data flows & platform goals
Questions about accounting, APIs, database restructuring, mapping, monitoring and new target platforms.
Directly to the answers
Delphi
Delphi for specialist applications
Why Delphi can remain strong for mature business logic, reports and productive desktop processes.
Directly to the answers
C#
C# for services & portals
Questions about REST, integrations, portals, backend services and stable operation.
Directly to the answers
Architecture
Layer-3 architecture
Questions about separating UI, business logic and data access and why this is directly economically relevant.
Directly to the answers
Modernization
Delphi modernization
Questions about migration path, risk, preserving business logic and staged renewal during ongoing operations.
Directly to the answers
Data access
BDE replacement
Questions about FireDAC, native drivers, SQL peculiarities, deployment and database reorganization.
Directly to the answers
Technology
Delphi Multiplatform
Questions about a shared codebase for Windows, macOS and Linux with controlled platform boundaries.
Directly to the answers
Server architecture
REST servers & services
Questions about APIs, Windows and Linux services, server logic, monitoring and operational responsibility.
Directly to the answers
Platform
Windows 11 ARM64
Questions about new hardware, native dependencies, drivers, builds and rollout paths.
Directly to the answers
Specialist software
Custom specialist software & Layer-3
These questions typically arise when standard software is no longer functionally sufficient and a company wants to know whether a custom system can really be built economically, maintainably and extensibly.
With custom specialist software it’s not just about individual screens, but about roles, data, validation paths and an architecture that remains flexible later on.
Is custom specialist software only sensible for very large companies?
No. It pays off whenever standard software represents processes only with detours, media breaks or expensive special rules and the real value lies in clean business logic.
Why do you emphasize Layer-3 so strongly in specialist applications?
Because only the separation of UI, business logic and data access ensures that reporting, new clients, services and future extensions remain economically controllable.
Can you also step into existing legacy processes?
Yes. Especially then our work becomes powerful because we first make business processes, existing data and legacy logic readable and from that develop a viable target architecture.
Read the topic in detail
If you want to move from this FAQ to the more in-depth specialist page, you will find there the broader context with architecture, examples, decision criteria and related topics.
View custom specialist software & Layer-3 applications in detail
Performance
Multiplatform with Delphi
At this point companies usually ask not only about a technical possibility but about a robust strategy: which parts remain shared, what has to be handled platform-specifically and how to avoid costly parallel development?
Multiplatform only becomes valuable when the same business logic remains controlled across multiple target systems and platform-specific peculiarities are made visible early.
Can Delphi be used to cover macOS, Linux, iOS and Android besides Windows?
Yes. Depending on the project goal we plan desktop targets, mobile interfaces and server-near components from a common business line instead of building each platform anew.
How do you prevent multiplatform projects from diverging functionally?
With a shared code and architecture strategy: business rules, data model and processes remain central while platform-specific differences are deliberately encapsulated.
Are mobile expansion stages still possible later?
Yes. If architecture, services and interfaces are prepared cleanly, iOS or Android targets can be connected much more controllably later on.
Read the topic in detail
If you want to move from this FAQ to the more in-depth specialist page, you will find there the broader context with architecture, examples, decision criteria and related topics.
Performance
Services, REST servers & portals
Here, rights, data flows, logging and business rules must remain consistent. That’s why we treat the topic not as a web add-on but as an orderly extension of the same application line.
Portals, REST APIs and services only sell well if they do not stand next to the core system functionally but continue the same data and role logic cleanly.
Do you develop both REST servers and Windows and Linux services?
Yes. Background services, APIs, imports, exports, portals and technical operational logic are part of our recurring tasks.
When does a specialist application additionally need a portal?
Whenever customers, partners or internal roles should access the same processes in a controlled way without duplicating business rules in separate interfaces.
How do rights, logging and processes remain consistent between client and server?
By not hiding business rules in individual endpoints or UIs, but by creating a clear business middle layer that client, portal and service can use together.
Read the topic in detail
If you want to move from this FAQ to the more in-depth specialist page, you will find there the broader context with architecture, examples, decision criteria and related topics.
Integration
Interfaces, data flows & platform goals
These questions usually arise when data quality, traceability and future platform changes become more important than pure data transfer from A to B.
Interfaces often seem like side issues. In reality they determine data quality, traceability, platform migration and stable operation.
Can existing interfaces and data flows be renewed without a big bang?
Yes. In many projects we reorder mapping, database paths, jobs and integrations step by step so that real processes can continue to run.
Do you also take over accounting and third-party system integrations?
Yes. Especially accounting, APIs, CRM, warehouse, licensing logic or industry-specific third-party systems must be documented, observable and integrated in a functionally controllable way.
Do you consider platform goals like Windows 11 ARM64 in such integration projects from the start?
Yes. New target platforms, native dependencies and future deployment paths belong early in the same planning as interfaces and data flow logic.
Read the topic in detail
If you want to move from this FAQ to the more in-depth specialist page, you will find there the broader context with architecture, examples, decision criteria and related topics.
Delphi
Delphi for specialist applications
This is about the fundamental question of when Delphi is still a deliberate architectural choice today and when other components should usefully complement or take over.
In companies Delphi is rarely about nostalgia, but about how mature business logic, desktop processes and multiple target platforms can be continued economically and cleanly.
Why do you still deliberately rely on Delphi today?
Because Delphi offers a strong combination in many specialist systems of mature business logic, performant desktop processes, database proximity and controllable further development.
Is Delphi only interesting for legacy modernization?
No. Delphi is also suitable for new specialist applications when productive desktop workflows, reports, local integration and a common business base for multiple platforms are important.
Where are the limits of Delphi?
Primarily where an initiative is primarily portal-, service- or cloud-centered. Then we consciously combine Delphi with C#, REST servers or web components instead of forcing everything into one tool.
Read the topic in detail
If you want to move from this FAQ to the more in-depth specialist page, you will find there the broader context with architecture, examples, decision criteria and related topics.
C#
C# for services & portals
This FAQ is aimed at companies that understand C# not as an end in itself but as a strong component for portals, APIs, integrations and service-oriented architecture parts.
For us C# is especially strong when web portals, APIs, services, integrations and a calm operational footprint are in focus.
When is C# the better choice compared to Delphi?
Primarily when a project consists mainly of REST APIs, portals, backend services, integrations or cloud-near operating models.
Do you also use C# together with existing Delphi systems?
Yes. That combination is often sensible: Delphi carries productive business logic in the client while C# cleanly complements services, portals and API layers.
What are typical risks in C# projects?
Too often teams build technically modern solutions too quickly without cutting roles, business logic, logging, deployment and real operational questions cleanly early enough. This is exactly where we intervene.
Read the topic in detail
If you want to move from this FAQ to the more in-depth specialist page, you will find there the broader context with architecture, examples, decision criteria and related topics.
Architecture
Layer-3 architecture
Layer-3 is often explained theoretically. In practice, however, this structure directly determines whether new clients, services, tests and extensions can dock on quietly or fall apart expensively.
Layer-3 is not a textbook term but a very practical response to grown monoliths, contradictory extensions and costly couplings in everyday life.
Why is Layer-3 so important for specialist systems?
Because only the clean separation of UI, business logic and data access ensures that extensions, tests, services and new platforms do not immediately fail at the monolith.
Is Layer-3 only sensible for large projects?
No. Especially medium-sized systems benefit greatly because later requirements can be connected much more controllably.
What is the most common mistake with Layer-3?
That layers are only drawn formally while the actual rules remain hidden in the UI code or directly in SQL special paths. Then the structure exists only on slides, not in the system.
Read the topic in detail
If you want to move from this FAQ to the more in-depth specialist page, you will find there the broader context with architecture, examples, decision criteria and related topics.
Modernization
Delphi modernization
These answers are especially helpful where a legacy application is still functionally strong but has collected too many technical bottlenecks to carry new requirements cleanly.
The critical point in modernization is rarely just the UI. It is usually about business logic, data, dependencies and a migration strategy that works in day-to-day operation.
Does an old Delphi application have to be replaced completely?
No. Often a controlled rebuild makes more sense: renew data access, decouple logic, add services and modernize interfaces selectively.
How do you avoid operational disruption during modernization?
Through clear intermediate stages, clean interfaces and a migration path in which old and new parts can coexist in a controlled way.
Can existing business logic later move into services or portals?
Yes. That is exactly why we extract business logic from UI-near legacy code and bring it into a structure that clients, services and APIs can use together.
Read the topic in detail
If you want to move from this FAQ to the more in-depth specialist page, you will find there the broader context with architecture, examples, decision criteria and related topics.
Data access
BDE replacement
The BDE is rarely just an old driver. It is usually tied to historical SQL logic, database assumptions and deployment paths. That’s why we answer the topic here somewhat more broadly.
The BDE is rarely just a single technical component. It is tied to SQL, deployment, drivers, encodings and historical side effects. Therefore we treat the replacement as a modernization step and not as a component swap.
Is a switch to FireDAC or native drivers possible without a complete rebuild?
Yes, often in stages. It is important to check SQL, data types, transactions and special cases carefully instead of just replacing components 1:1.
Why does BDE replacement almost always affect the database structure as well?
Because old tables, indexes, encodings and historically grown SQL paths often become visible and should be cleaned up for stability and performance.
What do you gain concretely through native database connectivity?
Easier deployment, better maintainability, controllable connections and a significantly better foundation for services, APIs and future extensions.
Read the topic in detail
If you want to move from this FAQ to the more in-depth specialist page, you will find there the broader context with architecture, examples, decision criteria and related topics.
Technology
Delphi Multiplatform
This FAQ highlights the technical side of the multiplatform strategy: codebase, packaging, system proximity, release processes and the question when multiple clients really become economical.
Multiplatform only works cleanly if codebase, data model, platform differences and deployment are planned consciously. This is where the actual project value arises.
Can the same application really run on Windows, macOS and Linux?
Yes, if UI, business logic, platform peculiarities and release processes are not mixed but cleanly structured.
What is the most common mistake in multiplatform projects?
Thinking too late about file systems, printing, signing, target platforms, packaging and UI differences. Then multiplatform quickly becomes expensive and inconsistent.
Can services and APIs use the same business logic?
Yes. A good architecture ensures that not every platform develops its own business special path.
Read the topic in detail
If you want to move from this FAQ to the more in-depth specialist page, you will find there the broader context with architecture, examples, decision criteria and related topics.
Server architecture
REST servers & services
When APIs and services only sound technically modern but are not cleanly cut functionally, they quickly become a problem. This FAQ classifies exactly these decisions.
Many systems do not fail because of the API idea, but because server logic is later improvised onto a desktop inventory. We plan these parts consciously together.
When does a specialist application additionally need a REST server?
As soon as multiple clients, portals, mobile accesses, external integrations or decoupled processes should use the same business logic in a controlled way.
Do you also support Windows and Linux services?
Yes. Background processes, scheduling, synchronization, exports, license services and technical companion processes are part of our typical tasks.
How is business consistency maintained between client, REST and service?
Through an architecture in which business rules are not hidden in individual interfaces but remain jointly usable and traceable.
Read the topic in detail
If you want to move from this FAQ to the more in-depth specialist page, you will find there the broader context with architecture, examples, decision criteria and related topics.
Platform
Windows 11 ARM64
ARM64 affects many applications earlier than expected. This FAQ answers the typical questions around dependencies, testing, installers and the economic assessment of new target hardware.
ARM64 is no longer an exotic side topic but a real target platform. Those who consider it early avoid later technical dead ends in deployment and native dependencies.
Why should Windows 11 ARM64 already be considered today?
Because new hardware classes and mobile workplaces increasingly rely on it and technical rework later is significantly more expensive than an early architectural decision.
What is particularly critical for Delphi and native dependencies on ARM64?
Above all external libraries, database drivers, installers, setup processes and tests on real target hardware must be checked early.
Does ARM64 require an entirely separate product?
Not necessarily. Often it is sufficient to prepare build and deployment paths cleanly and to decouple critical native dependencies in time.
Read the topic in detail
If you want to move from this FAQ to the more in-depth specialist page, you will find there the broader context with architecture, examples, decision criteria and related topics.
Turn this FAQ into a concrete project discussion?
Then the next sensible step is not another collection of buzzwords, but a structured assessment of your inventory: which business logic exists, where the current architecture is slowing you down, which interfaces are critical and which expansion path is technically truly viable?