FAQ landing page
Key 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, the overview pages and the technical 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 prospects can quickly see which topics we are proficient in regarding project initiation, services, Delphi, C#, Layer-3, portals, modernization, data access and platform strategy.
You can either jump directly to a topic block or switch from below to the respective in-depth subpage. This keeps the page usable both as a quick entry point and as a structured FAQ hub.
Project initiation
Project initiation, architecture & collaboration
Questions about an appropriate starting point, initial assessment and early architectural decisions.
Go directly to the answers
Services
Services overview
Questions on taking over existing systems, modernization, services, data access and long-term support.
Go directly to the answers
Technologies
Technology and architecture at a glance
Questions about Delphi, C#, Layer-3, platform choice and the technical direction across multiple expansion stages.
Directly to the answers
Projects
Project snapshots and reference patterns
Questions about project size, operational responsibility, hosting, product logic and long-lived systems.
Directly to the answers
Enterprise software
Custom enterprise software & Layer-3
Questions about cost-effectiveness, process logic, roles, data and long-term extensibility.
Directly to the answers
Capabilities
Multiplatform with Delphi
Questions about Windows, macOS, Linux and later iOS and Android paths derived from a common domain logic.
Directly to the answers
Capabilities
Services, REST servers & portals
Questions about portals, APIs, Windows and Linux services as part of the same domain architecture.
Directly to the answers
Integration
Interfaces, data flows & platform objectives
Questions about accounting, APIs, database refactoring, mapping, monitoring and new target platforms.
Directly to the answers
Delphi
Delphi for enterprise applications
Why Delphi can remain strong for evolved 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 the separation of UI, business logic and data access and why that is directly relevant to cost-effectiveness.
Directly to the answers
Delphi team
Delphi developers from Freiburg
Questions about external support, takeover of existing systems and technical responsibility in mature Delphi systems.
Direct to answers
Support
Delphi-Maintenance & Support
Questions about stabilization, ongoing development, release reliability and reduction of single-person knowledge.
Direct to answers
Modernization
Delphi Modernization
Questions about migration path, risk, preservation of business logic and phased renewal during operation.
Direct to answers
Data access
BDE Replacement
Questions about FireDAC, native drivers, SQL peculiarities, deployment and database reorganization.
Direct to answers
PostgreSQL
Delphi, PostgreSQL & FireDAC
Questions about PostgreSQL migration, native drivers, SQL behavior and a controlled data access transition.
Direct to answers
Delphi REST
Delphi REST API & REST Server
Questions about REST with Delphi, API design, shared business logic and clean server architecture.
Direct to answers
Services
Windows- & Linux-Services
Questions about background services, scheduling, monitoring, restart behavior and a clean operational scope.
Direct to answers
Technology
Delphi Multiplatform
Questions about a shared codebase for Windows, macOS and Linux with controlled platform boundaries.
Direct to answers
Server architecture
REST-Server & Services
Questions about APIs, Windows- and Linux-services, server logic, monitoring and operational responsibility.
Direct to answers
Platform
Windows 11 ARM64
Questions about new hardware, native dependencies, drivers, builds and rollout paths.
Direct to 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 does technical orientation emerge, and how does an idea become a reliable entry into a real project?
On the homepage the first orientation questions usually appear: How should a project sensibly begin, which architectural questions should be resolved early, and when is modernization preferable to a rushed redevelopment?
When is Delphi modernization worthwhile instead of a complete redevelopment?
When domain logic, processes and the data model are valuable, a controlled refactor is often more economical than a fresh start that entails feature loss and high rollout risk.
Can the same domain logic run for Windows, macOS and Linux?
Yes. Especially in Delphi projects we design shared business logic and separate the user interface, services and data access so that multiple platforms can be cleanly served.
Does Net-Base also build REST servers and background services?
Yes. Windows and Linux services, REST APIs, integration layers and deployment are part of the architecture for us and are not added on afterwards.
How does a typical project start?
Usually with a structured inventory: goals, existing systems, database, platforms, interfaces and operational risks. From this a realistically tailored starting point emerges.
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 with architecture, examples, decision rationales and related topics.
Services
Overview of services
On the services page the broadest follow-up questions usually arise: What do we take on specifically, how far does our technical responsibility extend and how do modernization, integrations, operations and ongoing development interact?
Especially with evolved applications the same functional and technical questions often arise. We resolve these points early, before a project becomes an ill-defined large-scale undertaking.
Do you also take on existing Delphi systems?
Yes. We regularly step into evolved Delphi applications, analyze the existing system, data access, architecture and edge cases, and continue development on that basis in a controlled manner.
Can REST servers, portals and desktop clients be created as part of a single project?
Yes. Especially for enterprise applications we deliberately plan these components together so that the same business logic does not splinter into multiple bespoke solutions.
Is a BDE replacement possible without a full system-wide replacement?
In many cases yes. We extract data access, SQL and deployment step by step from the legacy structure and build a native, maintainable integration.
Do you also support operations and ongoing development?
Yes. Release processes, hosting, fault analysis, database maintenance and later extensions are part of our scope of work.
Read the topic in detail
If you move from this FAQ to the in-depth technical page, you will find there the broader context including architecture, examples, decision rationales and related topics.
Technologies
Technology and architecture overview
This FAQ consolidates the typical orientation questions for technology decision-making: When is Delphi a strong choice, when is C# the better building block and how does a clean architecture bring multiple platforms, services and clients together in a controlled way?
Technological decisions must fit the team, the domain and operations. That is precisely why we do not address these questions abstractly, but always with the concrete system in mind.
When is Delphi sensible compared to a complete new platform?
Whenever mature domain logic, high-performance desktop processes and multi-platform goals are to be carried forward economically, rather than needlessly 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 like Windows 11 ARM64 early on?
Yes. New target hardware and deployment paths are examined early so they do not become costly special projects later.
Read more on the topic in detail
If you move from this FAQ to the in-depth technical page, you will find there the broader context including architecture, examples, decision rationales and related topics.
Projects
Project profiles and reference patterns
Those who view the projects page usually want to understand which kind of undertakings we actually support: one-off tools or longer-lived systems with operations, access control, versions, integrations and genuine ongoing development.
Many projects appear different at first and yet share common patterns: evolved domain logic, integrations, access control, versions, operational concerns and long-term extensibility.
Do you work primarily on one-off single tools or on longer-lived systems?
The focus is on systems with lifecycle, responsibility and ongoing development: enterprise applications, platforms, services, portals and product logic.
Can existing products or internal systems be modernized in parallel?
Yes. Especially for long-established systems we often plan a phased evolution so that operations and modernization fit together.
Is hosting and technical operations part of your work?
Yes. Release, hosting, monitoring and operational responsibility are incorporated into our project planning so that the finished solution is not only developed but also operated reliably.
Read more on 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 rationale and related topics.
Enterprise software
Custom enterprise software & Layer-3
These questions typically arise when off-the-shelf software no longer meets functional requirements and a company needs to know whether a custom system can be built economically, maintainably and extensibly.
Especially in custom enterprise software it’s not just about individual screens, but about roles, data, approval workflows and an architecture that remains adaptable over time.
Is custom enterprise software only suitable for very large companies?
No. It makes sense whenever standard software models processes only via workarounds, media breaks or expensive special rules, and the real value lies in clean domain logic.
Why do you emphasize Layer-3 so strongly in enterprise applications?
Because only the separation of UI, business logic and data access ensures that reporting, new clients, services and future extensions remain economically manageable.
Can you also integrate into established legacy processes?
Yes. That’s where our work is strongest: we make domain processes, existing data and legacy logic readable and derive a robust target architecture from them.
Read more on 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 rationale 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 do you avoid creating an expensive parallel implementation?
Multiplatform becomes valuable only when the same domain logic remains centrally controlled across multiple target systems and platform-specific peculiarities are surfaced early.
Can Delphi be used to include, in addition to Windows, also macOS, Linux, iOS and Android?
Yes. Depending on the project goal, we plan desktop targets, mobile interfaces and server-side components from a common domain-driven line, rather than reimplementing the domain logic for each platform.
How do you prevent multiplatform projects from diverging functionally?
Through a shared code and architecture strategy: business rules, data model and processes remain central, while platform-specific differences are deliberately encapsulated.
Are mobile extensions possible at a later stage?
Yes. If architecture, services and interfaces are prepared cleanly, iOS or Android targets can be integrated much more controllably later.
Read the topic in detail
If you switch from this FAQ to the in-depth technical page, you will find the broader context there, including architecture, examples, decision rationale and related topics.
Services
Services, REST-Server & Portale
Here, rights, data flows, logging and domain rules must remain together. For that reason 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 perform well when they are not functionally separate from the core system, but cleanly carry forward the same data and role logic.
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 an enterprise application additionally require a portal?
Whenever customers, partners or internal roles need controlled access to the same processes, without duplicating domain rules in separate interfaces.
How do rights, logging and processes remain consistent between client and server?
By not hiding domain rules in individual endpoints or UIs, but by creating a clear domain core that client, portal and service can use jointly.
Read the topic in detail
If you switch from this FAQ to the in-depth technical page, you will find the broader context there, including architecture, examples, decision rationale and related topics.
Integration
Interfaces, data flows & platform goals
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 side topics. 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 take on financial accounting and third-party system integrations?
Yes. In particular financial accounting (Fibu), APIs, CRM, inventory, license logic or industry-specific third-party systems must be connected with clear documentation, observability and domain-controllable integration.
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 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 in-depth technical page, you will find there the broader context with architecture, examples, decision rationale and related topics.
Delphi
Delphi for enterprise applications
This is about the fundamental question of when Delphi remains a deliberate architectural choice today and when other components should sensibly complement or take over parts of the solution.
In enterprises, Delphi is rarely about nostalgia; it is about how established domain logic, desktop processes and multiple target platforms can be continued in a technically and economically clean way.
Why do you still deliberately rely on Delphi today?
Because Delphi provides, in many enterprise applications, a strong combination of mature business logic, high-performance desktop processes, proximity to the database and controllable evolution.
Is Delphi only relevant for legacy modernization?
No. Delphi also makes sense for new enterprise applications when productive desktop workflows, reports, local integration and a shared domain foundation for multiple platforms are important.
Where are the limits of Delphi?
Primarily where an initiative is portal-, service- or cloud-centric. In those cases we deliberately combine Delphi with C#, REST-servers or web components instead of forcing everything into a single tool.
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 rationale and related topics.
C#
C# for services & portals
This FAQ is aimed at companies that see C# not as an end in itself, but as a robust building block for portals, APIs, integrations and service-oriented architectural components.
For us, C# is especially effective when web portals, APIs, services, integrations and a stable operational footprint are the priority.
When is C# the better choice compared to Delphi?
Primarily when a project consists mainly of REST-APIs, portals, backend services, integrations or cloud-proximate operational models.
Do you use C# together with existing Delphi systems?
Yes. That combination is often sensible: Delphi hosts productive domain logic in the client, while C# cleanly complements services, portals and API layers.
What are typical risks in C# projects?
Often teams move too quickly to technical modernity without cutting roles, domain logic, logging, deployment and real operational concerns cleanly early enough. That is precisely where we focus our work.
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 rationale and related topics.
Architecture
Layer-3 architecture
Layer-3 is often explained theoretically. In practice, however, this structure very directly determines whether new clients, services, tests and extensions attach smoothly or fall apart at high cost.
Layer-3 is not a textbook term but a very practical response to grown monoliths, conflicting extensions and costly couplings in daily operation.
Why is Layer-3 so important for enterprise applications?
Because only a clean separation of UI, business logic and data access ensures that extensions, tests, services and new platforms do not fail at the monolith.
Is Layer-3 only suitable for large projects?
No. Medium-sized systems in particular benefit significantly, because later requirements can be integrated in a much more controlled way.
What is the most common mistake with Layer-3?
That layers are drawn only formally while the actual rules remain hidden in UI code or in SQL special paths. Then the structure exists only on slides, not in the system.
Read the topic in detail
If you want to switch from this FAQ to the 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
This request is rarely about a single available person. Usually the question behind it 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 seldom only about available capacity. Mostly it is about a reliable takeover of existing systems, architecture, data access and real domain responsibility.
When is an external Delphi developer appropriate?
Primarily when institutional 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 precisely a focus: we analyze legacy code, database, deployment, special cases and business processes and continue development from there in a controlled manner.
Is it only about programming or also about technical direction?
It explicitly also concerns direction. For us, good Delphi development includes architecture, data access, integrations, REST-services and real-world operation.
Read the topic in detail
If you want to switch from this FAQ to the in-depth technical page, you will find there the broader context with architecture, examples, decision rationales and related topics.
Support
Delphi maintenance & support
Maintenance often sounds smaller than it is. In practice it is about stable releases, visible risks, technical order and the question of how an evolved system can be further developed without disruption.
Maintenance for grown Delphi systems is more than bug fixing. It concerns release safety, data consistency, technical debt and how new requirements can be integrated into the existing system with minimal disruption.
What does good Delphi maintenance include?
Error 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 begins with stabilization, surfacing risks and a prioritized list of technical and functional improvements.
How do you reduce dependency on single-expert knowledge?
By documenting data paths, components, build steps and critical domain logic in a structured way and by turning implicit knowledge back into traceable system logic.
Read the topic in detail
If you 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 primarily helpful where a legacy application is still strong functionally but has accumulated too many technical bottlenecks to carry new requirements cleanly.
The critical point in modernization is rarely just the UI. Most often it is about domain logic, data, dependencies and a migration strategy that works in day‑to‑day operations.
Does an old Delphi application need to be completely replaced?
No. Often a controlled refactor is more sensible: 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 that allows old and new parts to coexist in a controlled way.
Can existing domain logic later be moved into services or portals?
Yes. That is precisely why we extract business logic from UI‑proximate legacy code and place it into a structure that clients, services and APIs can use jointly.
Read the topic in detail
If you 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.
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 exactly why we address the topic here in a deliberately broader way.
The BDE is rarely just a single technical component. It is tied to SQL, deployment, drivers, character sets 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 thoroughly examine SQL, data types, transactions and special cases, rather than only replacing components 1:1.
Why does the BDE replacement almost always also affect the database structure?
Because old tables, indexes, character sets and historically grown SQL paths often become visible, which should be cleaned up to improve stability and performance.
What concrete benefits does native database connectivity provide?
Simpler 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 detailed technical page, you will find there the broader context with architecture, examples, decision rationales and related topics.
PostgreSQL
Delphi, PostgreSQL & FireDAC
Those who use PostgreSQL and BDE-Ablösung mit nativer Anbindung usually want more than just a new component. Often the underlying question is how to bring data access, SQL, deployment and legacy business logic back into a viable alignment.
With PostgreSQL and FireDAC it’s not just about a new connection component. Typically it implies a larger step toward more robust SQL, better deployment and more 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 path?
FireDAC is often a very good approach, but not a blind swap. Decisive are SQL behaviour, data types, transactions, error paths and the concrete existing system.
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, provided the data model and domain logic are properly considered.
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 with architecture, examples, decision rationales 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 is effective when APIs are not detached alongside the existing system, but properly carry permissions, business logic, data model and operations.
Can you build production REST APIs with Delphi?
Yes. Especially when the same domain logic already lives in the Delphi codebase, a cleanly designed REST server is often more economical than an entirely new parallel world.
When is a REST server worthwhile compared to direct database access?
As soon as multiple clients, portals, services or integrations need to use the same rules in a controlled way and direct SQL access becomes functionally too risky.
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 more on the topic
If you move from this FAQ to the in-depth technical page, you will find the broader context there: architecture, examples, decision rationale and related topics.
Services
Windows- & Linux-Services
Services are rarely just about a running process. More important are logging, observability, restart behavior, data consistency and the practical question which parts belong in the background and which do not.
Background services are often the invisible core of a system. They must run quietly, handle state transitions cleanly and fit robustly into operations with logging, restart capability and monitoring.
When does an enterprise application additionally require 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. This is often sensible, because business logic, data model and logging then do not diverge into multiple technical islands.
What is particularly important for production services?
Clear error handling, observable states, restart resilience, logging, deployment and domain-consistent processing instead of silent background magic.
Read more on the topic
If you move from this FAQ to the in-depth technical page, you will find the broader context there: architecture, examples, decision rationale and related topics.
Technology
Delphi Multiplatform
This FAQ examines 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 when codebase, data model, platform differences and deployment are planned deliberately. That is precisely where the real project value arises.
Can the same application really run on Windows, macOS and Linux?
Yes, if UI, business logic, platform-specific details and release processes are not mixed but cleanly structured.
What is the most common mistake in multiplatform projects?
Waiting too long to consider the file system, 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 each platform does not develop its own ad-hoc business variants.
Read the topic in detail
If you move from this FAQ to the in-depth technical page, you will find the broader context with architecture, examples, decision rationales and related topics.
Server architecture
REST-Server & Services
If APIs and services only sound technically modern but are not cleanly partitioned functionally, they quickly become a problem. This FAQ puts those 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 intentionally plan these parts 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 way.
Do you also support Windows- and Linux-services?
Yes. Background processes, scheduling, synchronization, exports, license services and technical ancillary processes are typical tasks for us.
How is business consistency maintained between client, REST and service?
Through an architecture in which business rules are not hidden in individual user interfaces, but remain jointly usable and traceable.
Read the topic in detail
If you move from this FAQ to the in-depth technical page, you will find the broader context with architecture, examples, decision rationales and related topics.
Platform
Windows 11 ARM64
ARM64 impacts many applications earlier than anticipated. This FAQ answers the typical questions about 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.
Why should Windows 11 ARM64 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 with Delphi and native dependencies on ARM64?
In particular, external libraries, database drivers, installers, setup processes and tests on actual target hardware must be validated early.
Does a completely separate product have to be created for ARM64?
Not necessarily. Often it is sufficient to properly prepare build and deployment paths and to decouple critical native dependencies ahead of time.
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 including architecture, examples, decision rationales and related topics.
Should this FAQ lead to a concrete project discussion?
Then the next sensible step is not another collection of buzzwords, but a structured assessment of your existing system: Which domain logic is present, where does the current architecture cause bottlenecks, which interfaces are critical and which extension path is technically viable?