Questions and Answers
Central FAQs at a glance
Appropriate performance and technical paths
Important deep dives into this topic
FAQ landing page
Central questions and answers on project start, 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 intentionally remain on their 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 start, 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 corresponding detailed subpage. This keeps the page usable both as a quick entry point and as a structured FAQ hub.
Project start
Project start, Architecture & Collaboration
Questions about a sensible entry point, system assessment and early architectural decisions.
Go directly to the answers
Services
Overview of services
Questions on takeover of existing systems, modernization, services, data access and long-term support.
Go 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.
Directly to the answers
Projects
Project profiles and reference patterns
Questions about project size, operational responsibility, hosting, product logic and longer-lived systems.
Directly to the answers
Enterprise software
Custom enterprise software & Layer-3
Questions about economic viability, 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 shared domain logic.
Directly to the answers
Performance
Services, REST-Server & 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 goals
Questions about accounting, APIs, database restructuring, mapping, monitoring and new target platforms.
Directly to the answers
Delphi
Delphi for enterprise applications
Why Delphi can remain strong with evolved business logic, reports and production 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 that is directly economically relevant.
Directly to the answers
Delphi-team
Delphi developers from Freiburg
Questions about external support, taking over existing systems and technical responsibility in evolved Delphi systems.
Directly to the answers
Support
Delphi-Maintenance & Support
Questions about stabilization, further development, release stability and reducing concentration of knowledge in individuals.
Directly to the answers
Modernization
Delphi-Modernization
Questions about migration path, risk, preservation of domain logic and staged renewal during operation.
Directly to the answers
Data access
BDE-Replacement
Questions about FireDAC, native drivers, SQL specifics, deployment and database reorganization.
Directly to the answers
PostgreSQL
Delphi, PostgreSQL & FireDAC
Questions about PostgreSQL migration, native drivers, SQL behavior and a controlled data access migration.
Directly to the answers
Delphi REST
Delphi REST-API & REST-Server
Questions about REST with Delphi, API design, shared domain logic and clean server architecture.
Directly to the answers
Services
Windows- & Linux-Services
Questions about background services, scheduling, monitoring, restart behavior and clear operational boundaries.
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-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 correct starting point: What should be clarified first, how is technical orientation established and how does an idea become a reliable entry into a real project?
On the homepage the first orientation questions usually appear: How does an initiative sensibly start, which architectural questions should be clarified early, and when is modernization more worthwhile than a hectic complete 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 presentation, services and data access so that multiple platforms can be cleanly supported.
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 merely retrofitted afterwards.
How does a typical project start?
Usually with a structured inventory: goals, existing systems, the database, platforms, interfaces and operational risks. From that a realistically tailored starting point emerges.
Read the topic in detail
If you 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.
Services
Services overview
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 further development interact?
Especially with evolved applications the same functional and technical questions often appear. We clarify these points early before an initiative turns into a diffuse large-scale project.
Do you also take over existing Delphi systems?
Yes. We regularly step into evolved Delphi applications, assess the existing system, data access, architecture and edge cases and continue building on that in a controlled manner.
Can REST servers, portals and desktop clients be delivered from a single project?
Yes. Especially for enterprise applications we deliberately plan these components together so that the same business logic does not split into multiple bespoke solutions.
Is a BDE replacement possible without a full swap-out?
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 further development?
Yes. Release processes, hosting, error analysis, database maintenance and later extensions are part of our scope of work.
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 wider context including architecture, examples, decision rationale and related topics.
Technologies
Technology and architecture overview
This FAQ consolidates the typical orientation questions for technology decisions: when is Delphi the stronger choice, when is C# the more appropriate building block, and how does a clean architecture coherently integrate multiple platforms, services and clients in a controlled way?
Technological decisions must fit the team, the domain and operations. That is why we do not address these questions abstractly, but always in the context of the concrete system.
When is Delphi preferable to a completely new platform?
Whenever existing domain logic, high-performance desktop processes and multi-platform objectives should be carried forward economically, instead of needlessly replacing core assets.
When do you use C# in addition?
Primarily for portals, web backends, REST services, integrations and service-oriented architectural parts that can be well integrated with existing desktop systems.
How important is Layer-3 in practice?
Very. Only the clean separation of UI, business logic and data access makes modernization, testing, services and future platform migrations manageable.
Do you consider new platforms 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 more in-depth technical page, you will find there the wider context including architecture, examples, decision rationale and related topics.
Projects
Project snapshots and reference patterns
Those who look at the project page usually want to understand what kind of undertakings we actually support: one-off tools or longer-lived systems with operation, an access control model, versions, integrations and genuine continued development.
Many projects initially appear different 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-lasting systems?
The emphasis is on systems with ongoing lifecycles, operational responsibility and continued 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 staged evolution so that operation and modernization align.
Is hosting and technical operation 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 can also be operated reliably and sustainably.
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.
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 truly be built in an economically viable, maintainable and extensible way.
Especially with custom enterprise software it’s not just about individual UI screens, but about roles, data, approval paths and an architecture that remains flexible over time.
Is custom enterprise software only appropriate for very large companies?
No. It pays off whenever standard software models processes only via workarounds, media discontinuities or costly special rules, and the actual value resides 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 controllable.
Can you also take on established legacy processes?
Yes. In such cases our work is particularly effective because we 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 in-depth technical page, you will find the broader context there, including architecture, examples, decision rationale and related topics.
View custom enterprise software & Layer-3 applications in detail
Services
Multiplatform with Delphi
Companies at this stage usually ask not only about a technical possibility but about a robust strategy: which parts remain shared, what must be handled platform-specifically, and how to avoid creating expensive parallel implementations?
Multiplatform becomes valuable only when the same domain logic remains consistently controlled across multiple target systems and platform-specifics are made visible early.
Can Delphi be used to cover, 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 shared domain logic, rather than rebuilding each platform’s domain logic anew.
How do you prevent multiplatform projects from diverging in domain logic?
Through a shared code and architecture strategy: domain 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 properly prepared, iOS or Android targets can be integrated much more controllably later.
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 rationale and related topics.
Capability
Services, REST-Servers & Portals
Especially here, permissions, data flows, logging and business rules must remain coherent. That is why we treat the topic not as a web bolt-on, but as an orderly extension of the same application line.
Portals, REST APIs and services only sell well when they do not stand beside the core system functionally, 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 operational technical logic are recurring elements of our work.
When does an enterprise application additionally require a portal?
Whenever customers, partners or internal roles need controlled access to the same processes without duplicating business rules across separate UIs.
How do permissions, 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 together.
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 rationale and related topics.
Integration
Interfaces, Data Flows & Platform Targets
These questions usually arise when data quality, traceability and future platform migrations become more important than the mere transfer of data from A to B.
Interfaces often appear to be 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 reorganize mappings, database paths, jobs and integrations step by step so that real processes can continue to run.
Do you also handle accounting and third-party system integrations?
Yes. Specifically financial accounting, APIs, CRM, inventory, licensing logic or industry-specific third-party systems must be integrated in a well-documented, observable and domain-controllable way.
Do you include platform targets like Windows 11 ARM64 in such integration projects from the outset?
Yes. New target platforms, native dependencies and future deployment paths should be part of the planning early on, alongside 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, reasons for decisions and related topics.
Delphi
Delphi for Enterprise Applications
This addresses the fundamental question of when Delphi remains a deliberate architectural choice today and when other components should sensibly complement or take over.
For Delphi in companies it is rarely about nostalgia; it is about how established domain logic, desktop processes and multiple target platforms can be continued economically and cleanly.
Why would 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, database proximity and controllable evolution.
Is Delphi only relevant for modernization of existing systems?
No. Delphi is also appropriate 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-centered. 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, reasons for decisions 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 component for portals, APIs, integrations and service-oriented architectural parts.
For us C# is particularly strong when web portals, APIs, services, integrations and a well-defined operational footprint are the focus.
When is C# the better choice compared with Delphi?
Especially when a project consists primarily of REST-APIs, portals, backend services, integrations or cloud-adjacent operational models.
Do you also use C# together with existing Delphi systems?
Yes. This combination is often sensible: Delphi houses productive domain logic in the client, while C# cleanly complements services, portals and API layers.
What are typical risks in C# projects?
Often technically modern solutions are built too quickly, without properly separating roles, domain logic, logging, deployment and real operational concerns early enough. That is precisely where we engage.
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, reasons for decisions 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 integrate smoothly or end up diverging at high cost.
Layer-3 is not a textbook term but a very practical response to grown monoliths, conflicting extensions and costly couplings in everyday 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 against the monolith.
Is Layer-3 only sensible for large projects?
No. Medium-sized systems in particular benefit greatly, because later requirements can be connected in a much more controlled way.
What is the most common mistake with Layer-3?
That you only draw the layers formally, while the actual rules remain hidden in the 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 rationale and related topics.
Delphi-Team
Delphi-Developers from Freiburg
This request is seldom only about an available individual. More often it is about whether a partner can reliably take over legacy code, domain logic, data access and the technical direction.
When searching for Delphi-developers, it’s rarely just about available capacity. More often it’s about a reliable takeover of the codebase, architecture, data access and genuine domain responsibility.
When is an external Delphi developer appropriate?
Primarily when knowledge of the existing system 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’s exactly a focus: we analyze legacy code, database, deployment, special cases and domain workflows and then continue in a controlled way.
Is it only about programming or also about technical direction?
It explicitly also concerns 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 there the broader context with 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 developed further with stability.
Maintenance in evolved Delphi systems is more than bug fixing. It relates to release safety, data consistency, technical debt and the question of how new requirements can be integrated into the existing system without disruption.
What is included in good Delphi maintenance?
Fault analysis, ongoing 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 overhaul?
Yes. Often it begins 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 and turning implicit knowledge back into traceable system logic.
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 rationales and related topics.
Modernization
Delphi-Modernization
These answers help especially 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 only the surface. It is usually 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 the data access, decouple the 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 where old and new parts can coexist in a controlled manner.
Can existing domain logic later transition into services or portals?
Yes. That is precisely why we extract business logic from legacy code close to the UI and put 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 in-depth technical page, there you will find the broader context with architecture, examples, decision rationales and related topics.
Data access
BDE Replacement
The BDE is rarely just an old driver. It is typically tied to historical SQL logic, database assumptions and deployment paths. That is why we address the topic here deliberately more broadly.
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 overhaul?
Yes, often in stages. What matters is to thoroughly examine SQL, data types, transactions and edge cases, rather than simply replacing components 1:1.
Why does the BDE replacement almost always also affect the database structure?
Because this often exposes old tables, indexes, character sets and historically grown SQL paths that should be addressed as part of the process for stability and performance.
What do you gain concretely from 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 in-depth technical page, you will find there the broader context with architecture, examples, decision rationale and adjacent 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 business logic can be brought back into a coherent, maintainable alignment.
With PostgreSQL and FireDAC it’s not only about a new connection component. Usually it represents a larger step toward more robust SQL, better 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 path?
FireDAC is often a very good approach, but not a blind swap. Decisive are SQL behavior, 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 business logic are properly considered.
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 adjacent topics.
Delphi REST
Delphi REST-API & REST-Server
This FAQ answers the typical fundamental question whether REST with Delphi is just a technical add-on or a serious server strategy. What matters is always how cleanly client, rules, data and operations are kept together.
REST with Delphi is robust when APIs are not isolated beside the existing system, but instead properly carry permissions, business logic, data model and operations.
Can you build production-ready REST APIs with Delphi?
Yes. Especially when the same domain logic already lives in the Delphi codebase, a cleanly separated 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 should consistently use the same rules and direct SQL access becomes too risky from a functional perspective.
How do you keep the Delphi client and REST consistent?
With 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 want to move from this FAQ to the in-depth technical page, you will find the broader context there: architecture, examples, decision criteria and adjacent topics.
Services
Windows- & Linux-Services
With services it’s rarely only about a running process. More important are logging, observability, restart behavior, 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 quietly, process state transitions cleanly and integrate robustly into operations with logging, restart and monitoring.
When does an enterprise application additionally need 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 sensible, because business logic, data model and logging do not split into multiple technical islands as a result.
What is especially important for production services?
Clear error handling, observable states, restart reliability, logging, deployment and a functionally consistent processing instead of silent background magic.
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: architecture, examples, decision criteria and adjacent 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 actually become economical.
Multiplatform only works cleanly when codebase, data model, platform differences and deployment are planned consciously. That is precisely where the actual project value is created.
Can the same application really run on Windows, macOS and Linux?
Yes, provided the UI, business logic, platform-specific characteristics and release processes are not mixed but cleanly separated.
What is the most common mistake in multi-platform 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 platforms do not each implement their own separate business logic.
Read the topic in detail
If you move from this FAQ to the in-depth technical page, you will find the broader context: architecture, examples, decision rationales 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 exactly 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 codebase. We intentionally plan these parts together.
When does an enterprise application additionally need a REST server?
As soon as multiple clients, portals, mobile accesses, 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 ancillary processes are among our typical tasks.
How is domain consistency maintained between client, REST and service?
Through an architecture in which business rules are not hidden in individual UIs 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: architecture, examples, decision rationales and related topics.
Platform
Windows 11 ARM64
ARM64 impacts many applications sooner than expected. This FAQ answers common questions regarding dependencies, testing, installers and the economic assessment of new target hardware.
ARM64 is no longer an exotic side topic but a real target platform. Considering it early avoids later technical dead ends in deployment and with native dependencies.
Why should Windows 11 ARM64 be considered today?
Because new hardware classes and mobile workstations 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 need to be developed for ARM64?
Not necessarily. Often it is sufficient to properly prepare build and deployment paths and to timely decouple critical native dependencies.
Read the topic in detail
If you move from this FAQ to the more detailed technical page, you will find the broader context with 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: what domain logic is present, where the current architecture creates bottlenecks, which interfaces are critical and which extension path is technically viable?
Next step
If you have a concrete modernization, API or platform question, we should establish the technical scope clearly and early.
Net-Base evaluates existing systems, data paths, interfaces and target platforms not in isolation, but in the context of domain logic, operations and future expansion.
- Current state, target state and technical risks are assessed jointly.
- REST, data access, portals and rollout are not deferred to a later stage as secondary consequences.
- You can see early on which path is economically and operationally viable.