Questions and Answers
Central FAQ Overview
FAQ landing page
Central questions and answers on project initiation, services, enterprise software, Delphi, architecture, portals, services and modernization.
This page collects the most frequent questions from our homepage, overview pages and technical subpages in one place. The compact FAQs intentionally remain on the respective detail pages. Here we additionally arrange them as a landing page so that prospects can quickly see which topics we truly master in project initiation, services, Delphi, C#, Layer-3, portals, modernization, data access and platform strategy.
You can either jump directly to a topic block or from below navigate to the corresponding in-depth subpage. This keeps the page usable both as a quick entry and as a structured FAQ hub.
Project initiation
Project initiation, architecture & collaboration
Questions about an effective start, system assessment and early architectural decisions.
Directly to the answers
Services
Overview of services
Questions about taking over existing systems, modernization, services, data access and long-term support.
Directly to the answers
Technologies
Technology and architecture overview
Questions about Delphi, C#, Layer-3, platform selection and the technical direction across multiple expansion stages.
Direct to the answers
Projects
Project snapshots and reference patterns
Questions about project size, operational responsibility, hosting, product logic and long-lived systems.
Direct to the answers
Enterprise software
Custom enterprise software & Layer-3
Questions about cost-effectiveness, process logic, roles, data and long-term extensibility.
Direct to the answers
Performance
Multiplatform with Delphi
Questions about Windows, macOS, Linux as well as later iOS and Android paths from shared domain logic.
Direct to the answers
Performance
Services, REST-Server & Portals
Questions about portals, APIs, Windows- and Linux-services as part of the same domain architecture.
Direct to the answers
Integration
Interfaces, data flows & platform goals
Questions about accounting (Fibu), APIs, database restructuring, mapping, monitoring and new target platforms.
Direct to the answers
Delphi
Delphi for enterprise applications
Why Delphi can remain strong for mature business logic, reporting and production desktop processes.
Direct to the answers
C#
C# for Services & Portals
Questions about REST, integrations, portals, backend services and stable operation.
Direct to the answers
Architecture
Layer-3-Architecture
Questions about the separation of UI, business logic and data access and why this is directly relevant economically.
Direct to the answers
Delphi-Team
Delphi-Developers from Freiburg
Questions about external support, takeover of existing systems and technical responsibility in evolved Delphi systems.
Direct link to answers
Delphi-Team
Delphi-Developers for Munich
Questions about external support, takeover of existing systems and technical responsibility in established Delphi systems for companies in the Munich area.
Direct link to answers
Delphi-Team
Delphi-Developers for Berlin
Questions about external support, takeover of existing systems and technical responsibility in established Delphi systems for companies in the Berlin area.
Direct link to answers
Support
Delphi-Maintenance & Support
Questions about stabilization, further development, release reliability and reducing reliance on individual knowledge.
Direct link to answers
Modernization
Delphi-Modernization
Questions about migration path, risk, preservation of business logic and phased renewal during live operation.
Direct link to answers
Data Access
BDE-Replacement
Questions on FireDAC, native drivers, SQL specifics, deployment and database reorganization.
Direct link to answers
PostgreSQL
Delphi, PostgreSQL & FireDAC
Questions about PostgreSQL migration, native drivers, SQL behavior and a controlled data-access refactor.
Direct link to answers
Delphi REST
Delphi REST-API & REST-Server
Questions about REST with Delphi, API design, shared business logic and clean server architecture.
Direct link to answers
Services
Windows- & Linux-Services
Questions about background services, scheduling, monitoring, restart behavior and clean operational scope.
Direct link to answers
Technology
Delphi Multiplatform
Questions about a shared codebase for Windows, macOS and Linux with controlled platform boundaries.
Direct link to answers
Server architecture
REST-Server & 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
Project start
Project start, architecture & collaboration
Many initial questions are not about a single technology but about the right starting point: What should be clarified first, how is technical orientation established and how does an idea become a viable entry into a real project?
On the homepage the first orientation questions usually appear: How should an undertaking sensibly start, which architectural issues should be resolved early and when is modernization preferable to hasty redevelopment?
When is Delphi modernization preferable to a complete redevelopment?
If business logic, processes and the data model are valuable, a controlled refactor is often more economical than a fresh start with loss of functionality and high rollout risk.
Can the same business logic run for Windows, macOS and Linux?
Yes. Especially in Delphi projects we design shared business logic and separate user interface, services and data access so that multiple platforms can be served cleanly.
Does Net-Base also build REST servers and background services?
Yes. Windows- and Linux-services, REST-APIs, integration layers and deployment are part of our architecture and are not tacked on later.
How does a typical project start?
Usually with a structured inventory: goals, existing systems, database, platforms, interfaces and operational risks. From that a realistically tailored starting point is defined.
Read the topic in detail
If you want to move from this FAQ to the more in-depth technical page, you will find the broader context there with architecture, examples, decision rationales and related topics.
Services
Services at a glance
On the services page the widest range of follow-up questions usually arises: What do we take on concretely, how far does our technical responsibility extend and how do modernization, integrations, operations and further development interact?
Especially with mature applications the same functional and technical questions often recur. We clarify these points early, before an undertaking becomes an ill-defined large project.
Do you also take over existing Delphi systems?
Yes. We regularly step into established Delphi applications, analyze the existing system, data access, architecture and special cases, and extend them in a controlled manner.
Can REST servers, portals and desktop clients emerge from a single project?
Yes. Especially for enterprise applications we deliberately design these components together so that the same business logic does not fragment across multiple bespoke solutions.
Can a BDE replacement be done without a full system replacement?
In many cases, yes. We decouple data access, SQL and deployment from the legacy structure step by step and build a native, maintainable integration.
Do you also support operation and ongoing development?
Yes. Release processes, hosting, fault analysis, database maintenance and later extensions are part of our responsibilities.
Read the topic in detail
If you want to move from this FAQ to the in-depth technical page, there you will find the broader context with architecture, examples, decision rationale and related topics.
Technologies
Technology and architecture overview
This FAQ consolidates the typical orienting questions for technology decisions: when is Delphi advantageous, when is C# the better building block, and how does a clean architecture integrate multiple platforms, services and clients in a controlled manner?
Technological decisions must fit the team, the business 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 preferable to a complete new platform?
Whenever established domain logic, high-performance desktop processes and multiplatform goals should be continued economically, rather than recklessly replacing core assets.
When do you use C# in addition?
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 a clean separation of UI, business logic and data access makes modernization, testing, services and future platform migrations manageable.
Do you consider new platforms such as 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 the topic in detail
If you want to move from this FAQ to the in-depth technical page, there you will find the broader context with architecture, examples, decision rationale and related topics.
Projects
Project examples and reference patterns
Those who look at the project page usually want to understand which kind of projects we actually undertake: one-off tools or longer-lived systems with operation, rights concepts, versioning, integrations and genuine further development.
Many projects initially appear different and yet share common patterns: evolved domain logic, integrations, access control, versions, operational issues and long-term extensibility.
Do you primarily work on one-off standalone tools or on longer-lasting systems?
The focus is on systems that run in production, carry operational responsibility and require ongoing development: enterprise applications, platforms, services, portals and product logic.
Can existing products or internal systems be modernized in parallel?
Yes. Especially for longstanding systems we often plan a staged evolution so that operation and modernization align.
Is hosting and technical operations part of your work?
Yes. Release, hosting, monitoring and operational responsibility are integrated into our project planning so that the finished solution is not only developed but can also be operated reliably.
Read the topic in detail
If you want to move from this FAQ to the more detailed technical page, you will find there the broader context including architecture, examples, decision rationales and related topics.
Enterprise software
Custom enterprise software & Layer-3
These questions typically arise when standard software is no longer sufficient functionally and a company wants to know whether a custom system can actually be built in an economically viable, maintainable and extensible way.
With custom enterprise software it’s not just about individual screens, but about roles, data, verification paths and an architecture that remains flexible over time.
Is custom enterprise software only suitable for very large companies?
No. It is worthwhile whenever standard software models processes only by detours, media breaks or expensive special rules, and the actual value lies in clean domain logic.
Why do you emphasize Layer-3 so strongly for enterprise 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 engage with established legacy processes?
Yes. Our work is particularly effective in those cases because we first make domain 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 detailed technical page, you will find there the broader context including architecture, examples, decision rationales and related topics.
View custom enterprise software & Layer-3 applications in detail
Capabilities
Multiplatform with Delphi
At this point companies usually ask not only about a technical possibility, but about a reliable strategy: which parts remain shared, what must be handled platform-specifically and how to avoid an expensive duplicate development?
Multiplatform only becomes valuable when the same domain logic remains controlled across multiple target systems and platform-specific characteristics are exposed early.
Can Delphi be used, alongside Windows, to also cover macOS, Linux, iOS and Android?
Yes. Depending on the project objective, we plan desktop targets, mobile interfaces and server-side components from a common functional line, instead of rebuilding the domain logic separately for each platform.
How do you prevent multi-platform projects from diverging functionally?
Through a shared code and architecture strategy: business rules, the 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 attached later in a far more controlled manner.
Read the topic in detail
If you want to move from this FAQ to the in-depth technical page, you will find there the broader context with architecture, examples, decision rationales and adjacent topics.
Services
Services, REST-Servers & Portals
Especially here, permissions, data flows, logging and business rules must remain consistent. That is why we do not treat the topic as a web add-on, but as an orderly extension of the same application line.
Portals, REST-APIs and services only work well when they do not stand beside the core system functionally, but carry forward 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 task set.
When does an enterprise application additionally need a portal?
Whenever customers, partners or internal roles need controlled access to the same processes, without duplicating business rules across separate user interfaces.
How do permissions, logging and processes remain consistent between client and server?
By not hiding business rules in individual endpoints or UIs, but by creating a clear functional center that client, portal and service can use jointly.
Read the topic in detail
If you want to move from this FAQ to the in-depth technical page, you will find there the broader context with architecture, examples, decision rationales and adjacent topics.
Integration
Interfaces, Data Flows & Platform Targets
These questions usually arise when data quality, traceability and future platform migrations become more important than the pure data transfer from A to B.
Interfaces often appear to be peripheral. 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 reorganize mapping, database paths, jobs and integrations step by step so that real processes can continue to run.
Do you also implement financial accounting and third-party system integrations?
Yes. In particular, financial accounting, APIs, CRM, inventory, licensing logic or industry-specific third-party systems must be integrated with thorough documentation, observability and functional controllability.
Do you consider platform goals like Windows 11 ARM64 in such integration projects right from the start?
Yes. New target platforms, native dependencies and future deployment paths should be included 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 technical page, you will find there the broader context with architecture, examples, decision rationales and related topics.
Delphi
Delphi for enterprise applications
This is about the fundamental question of when Delphi is still a deliberate architectural choice today and when other components should sensibly complement or take over.
For Delphi in companies it’s rarely about nostalgia, but about how established domain logic, desktop processes and multiple target platforms can be continued in an economically sound way.
Why do you still deliberately choose Delphi today?
Because Delphi provides in many enterprise applications a powerful combination of established business logic, high-performance desktop processes, close database integration and controlled evolution.
Is Delphi only relevant for legacy modernization?
No. Delphi is also appropriate for new enterprise applications when productive desktop workflows, reports, local integration and a shared business core for multiple platforms are important.
Where are the limits of Delphi?
Primarily where a project is portal-, service- or cloud-centered. In those cases, we intentionally combine Delphi with C#, REST-servers or web components rather than forcing everything into a single tool.
Read the topic in detail
If you want to move from this FAQ to the more in-depth technical page, you will find there the broader context with architecture, examples, decision rationales and related topics.
C#
C# for services & portals
This FAQ is aimed at companies that want to understand C# not as an end in itself, but as a robust building block for portals, APIs, integrations and service-oriented architectural components.
C# is particularly strong for us when web portals, APIs, services, integrations and a stable operational footprint are in the foreground.
When is C# the better choice compared to Delphi?
Especially when a project primarily consists of REST-APIs, portals, backend services, integrations or cloud-adjacent operating models.
Do you also use C# together with existing Delphi-systems?
Yes. This combination is often appropriate: Delphi carries productive domain logic in the client, while C# cleanly complements services, portals and API layers.
What are typical risks in C# projects?
Often teams modernize technically too quickly, without separating roles, domain logic, logging, deployment and real operational concerns early enough and cleanly. That is precisely where we focus.
Read the topic in detail
If you want to move from this FAQ to the more in-depth technical page, you will find there the broader context with architecture, examples, decision rationales 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 integrate smoothly or will diverge at high cost.
Layer-3 is not a textbook term, but a very practical response to evolved monoliths, conflicting extensions and costly coupling in day-to-day operations.
Why is Layer-3 so important for enterprise applications?
Because only the clean separation of UI, business logic and data access ensures that extensions, tests, services and new platforms do not immediately fail against the monolith.
Is Layer-3 only sensible for large projects?
No. Especially mid-sized systems benefit strongly from it, because later requirements can be integrated in a much more controlled way.
What is the most common mistake with Layer-3?
That layers are only drawn formally while the actual rules remain hidden in UI code or directly in SQL special-case paths. Then the architecture 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 technical page, you will find there the broader context with architecture, examples, decision rationales and related topics.
Delphi-team
Delphi developers from Freiburg
Such requests are seldom only about an available person. Usually the question is whether a partner can reliably take over legacy assets, domain logic, data access and the technical direction.
When searching for Delphi developers, it is rarely just about available capacity. Mostly it is about a reliable takeover of existing assets, architecture, data access and genuine domain responsibility.
When is an external Delphi developer appropriate?
Especially when domain knowledge is missing, modernization has stalled, or an application needs to be further developed functionally without losing its substance.
Can you also take on established Delphi applications?
Yes. That is exactly a focus: we analyze legacy code, the database, deployment, special cases and domain processes and then continue development in a controlled manner.
Is it only about programming or also about technical direction?
It explicitly also concerns technical direction. For us, sound Delphi development encompasses architecture, data access, integrations, REST-services and real-world operation.
Read the topic in detail
If you move from this FAQ to the in-depth technical page, you will find the broader context covering architecture, examples, decision rationales and related topics.
Delphi-Team
Delphi developers for Munich
Such requests are rarely only about an available person. Usually the underlying question is whether a partner can reliably take over legacy assets, domain logic, data access and the technical direction.
Requests from Munich are rarely merely about free capacity. Most often they concern a reliable takeover of existing systems, architecture, data access and genuine domain responsibility in demanding enterprise environments.
When is an external Delphi developer for Munich appropriate?
Above all when knowledge of the existing system is missing, modernization has stalled, or an application needs to be developed further functionally without losing its substance.
Do you also work for companies in the Munich area without a local team?
Yes. That is precisely a focus: we analyze legacy code, the database, deployment, edge cases and domain workflows and build on that in a controlled manner, even when product ownership, operation and further development are distributed across multiple roles.
Is it only about programming or also about technical direction?
It explicitly also concerns technical direction. For us, sound Delphi development encompasses architecture, data access, integrations, REST-services and real-world operation.
Read the topic in detail
If you move from this FAQ to the in-depth technical page, you will find the broader context covering architecture, examples, decision rationales and related topics.
Delphi-Team
Delphi developers for Berlin
Such requests are rarely only about an available person. Usually the underlying question is whether a partner can reliably take over legacy assets, domain logic, data access and the technical direction.
Requests from Berlin are rarely merely about free capacity. Most often they concern a reliable takeover of existing systems, architecture, data access and genuine technical responsibility in rapidly changing product and platform environments.
When is an external Delphi developer for Berlin appropriate?
Above all when knowledge of the existing system is missing, a product or internal system must be developed faster, or modern APIs, portals and services need to connect to established Delphi logic.
Can you also take on hybrid landscapes composed of Delphi, services and web components?
Yes. We align legacy code, database, interfaces, background processes and new platform parts into a coherent technical line, rather than merely processing individual tickets.
Is it only about programming or also about technical direction?
It is explicitly also about direction. Good Delphi development, for us, includes architecture, data access, integrations, REST services and real-world operation.
Read the topic in detail
If you want to move from this FAQ to the more in-depth technical page, you will find the broader context there, including architecture, examples, decision rationale and related topics.
Support
Delphi Maintenance & Support
Maintenance often sounds smaller than it is. In practice it concerns stable releases, visible risks, technical order and the question of how an evolved system can be further developed with minimal disruption.
Maintenance for grown Delphi systems is more than bugfixing. It concerns release safety, data consistency, technical debt and the question of how new requirements can be integrated into the existing system without disruption.
What is part of good Delphi maintenance?
Fault analysis, further development, database maintenance, release support, technical documentation and an architecture that does not automatically make new requirements more expensive.
Can support start without a complete rebuild?
Yes. Often it starts with stabilization, making risks visible and a prioritized list of technical and functional improvements.
How do you reduce dependence on individual knowledge?
By documenting data paths, components, build steps and critical domain logic in a structured way, turning implicit knowledge back into traceable system logic.
Read the topic in detail
If you want to move from this FAQ to the more in-depth technical page, you will find the broader context there, including architecture, examples, decision rationale and related topics.
Modernization
Delphi Modernization
These answers are especially helpful where a legacy application remains strong functionally but has accumulated too many technical bottlenecks to cleanly carry new requirements.
The critical point in modernization is rarely only the UI. It is usually about domain logic, data, dependencies and a migration strategy that works in day-to-day operations.
Does a legacy Delphi application need to be completely replaced?
No. Often a controlled rebuild is more appropriate: renew data access, decouple logic, add services and selectively modernize user interfaces.
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 manner.
Can existing domain logic later be moved into services or portals?
Yes. That is exactly why we extract business logic from UI-near legacy code and place it into a structure that clients, services and APIs can use jointly.
Read the topic in detail
If you want to move from this FAQ to the more detailed specialist page, you will find there the broader context with architecture, examples, decision rationale 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 is precisely why we address the topic here in a somewhat broader way.
The BDE is rarely just a single technical component. It depends on SQL, deployment, drivers, character sets and historical side effects. For that reason we treat the replacement as a modernization step rather than a component swap.
Is switching to FireDAC or native drivers possible without a complete rework?
Yes, often in stages. What matters is to examine SQL, data types, transactions and special cases thoroughly, rather than simply replacing components 1:1.
Why does replacing the BDE almost always affect the database schema as well?
Because this often exposes old tables, indexes, character sets and historically grown SQL paths that should be cleaned up for stability and performance.
What are the concrete gains from native database connectivity?
Simpler deployment, better maintainability, controllable connections and a significantly stronger basis for services, APIs and future extensions.
Read the topic in detail
If you want to move from this FAQ to the more detailed specialist page, you will find there the broader context with architecture, examples, decision rationale and related topics.
PostgreSQL
Delphi, PostgreSQL & FireDAC
Those who use PostgreSQL and BDE-Ablosung mit nativer Anbindung usually want more than just a new component. Behind it often lies the question of how data access, SQL, deployment and legacy logic can be brought back into a sustainable alignment.
With PostgreSQL and FireDAC it’s not just about a new connection component. More often it is a larger step toward more robust SQL, improved deployment and controllable data management.
When is PostgreSQL a good choice for Delphi?
Whenever stability, multi-user operation, clear SQL paths, open infrastructure and clean extensibility for desktop, services or portals are important.
Is FireDAC always the right approach?
FireDAC is often a very good approach, but not as a blind swap. Critical factors are SQL behavior, data types, transactions, error paths and the existing estate.
Can BDE-, Paradox- or old SQL-systems migrate stepwise to PostgreSQL?
Yes. In many cases a controlled staged path is more economical than a hard cut, as long as the data model and business logic are considered throughout.
Read the topic in detail
If you switch from this FAQ to the in-depth technical page, you will find the wider context covering architecture, examples, decision rationale and related topics.
Delphi REST
Delphi REST-API & REST-Server
This FAQ answers the typical fundamental question whether REST with Delphi is merely a technical add-on or a serious server strategy. The decisive factor is always how cleanly client, rules, data and operations are held together.
REST with Delphi becomes effective when APIs are not detached alongside the existing system, but instead properly carry permissions, business logic, the data model and operations.
Can you build production REST APIs with Delphi?
Yes. Especially when the same domain logic already lives in the Delphi code base, a cleanly designed REST server is often more economical than an entirely new parallel system.
When is a REST server worthwhile compared to direct database access?
As soon as multiple clients, portals, services or integrations should use the same rules in a controlled way and direct SQL access becomes too risky from a business standpoint.
How do you keep Delphi client and REST consistent?
Through an architecture in which business rules are not hidden in forms, but are usable jointly by client, API and background processes.
Read the topic in detail
If you switch from this FAQ to the in-depth technical page, you will find the wider context covering architecture, examples, decision rationale and related topics.
Services
Windows- & Linux-Services
With services it’s rarely just about a running process. More important are logging, observability, restart, data consistency and the functional question of which parts belong in the background and which do not.
Background services are often the invisible core of a system. They must run reliably, process state transitions cleanly and fit robustly into operations with logging, restart and monitoring.
When does an enterprise application need additional Windows- or Linux-services?
Whenever imports, exports, scheduling, synchronization, license logic or integrations should not be tied to a logged-in desktop.
Can services and REST come from the same architecture?
Yes. That is often appropriate, because business logic, the data model and logging thereby do not split into multiple technical islands.
What is particularly important for production services?
Clear error handling, observable states, robust restart behavior, logging, deployment and domain-consistent processing instead of silent background magic.
Read the topic in detail
If you switch from this FAQ to the in-depth technical page, you will find the wider context covering architecture, examples, decision rationale and related topics.
Technology
Delphi Multiplatform
This FAQ examines the technical aspects of the multiplatform strategy: codebase, packaging, system-level concerns, release processes and the question of when multiple clients actually become economically viable.
Multiplatform only works reliably when the codebase, data model, platform differences and deployment are planned deliberately. That is where the real project value arises.
Can the same application really run on Windows, macOS and Linux?
Yes, provided the user interface, business logic, platform-specific peculiarities and release processes are not intermingled but cleanly structured.
What is the most common mistake in multiplatform projects?
Waiting too long to consider the filesystem, printing, signing, target platforms, packaging and UI differences. Multiplatform then quickly becomes costly and inconsistent.
Can services and APIs use the same business logic?
Yes. A sound architecture ensures that no platform implements its own special-case business logic.
Read the topic in detail
If you want to move from this FAQ to the in-depth technical page, you will find the broader context there with architecture, examples, decision criteria and related topics.
Server architecture
REST-Server & Services
If APIs and services only sound technically modern but are not cleanly defined from a domain perspective, they quickly become a problem. This FAQ puts these decisions into context.
Many systems do not fail because of the API idea, but because server logic is later improvised onto an existing desktop install base. We plan these parts deliberately together.
When does an enterprise application additionally require a REST server?
As soon as multiple clients, portals, mobile access, external integrations or decoupled processes need to use the same business logic in a controlled manner.
Do you also support Windows- and Linux-services?
Yes. Background processes, scheduling, synchronization, exports, license services and technical auxiliary processes are among our typical tasks.
How is business consistency maintained between client, REST and service?
By 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 in-depth technical page, you will find the broader context there 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 concerning 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 with native dependencies.
Warum sollte Windows 11 ARM64 heute schon beruecksichtigt werden?
Because new classes of hardware and mobile workplaces increasingly rely on it, and technical rework later is significantly more expensive than an early architectural decision.
Was ist bei Delphi und nativen Abhängigkeiten auf ARM64 besonders kritisch?
Above all, external libraries, database drivers, installers, setup processes and tests on real target hardware must be validated early.
Muss für ARM64 ein komplett eigenes Produkt entstehen?
Not necessarily. Often it is sufficient to properly prepare build and deployment paths and to decouple critical native dependencies early.
Thema im Detail weiterlesen
If you want to move from this FAQ to the more detailed technical page, you will find the broader context there: architecture, examples, decision rationale and related topics.
Aus FAQ soll ein konkretes Projektgespräch werden?
Then the next sensible step is not another roundup of buzzwords, but a structured assessment of your existing setup: which business logic is present, where the current architecture is a bottleneck, which interfaces are critical and which expansion path is technically viable?