At a glance
FAQ at a glance
FAQ landing page
Key questions and answers on project kickoff, services, enterprise software, Delphi, architecture, portals, services, and modernization.
This page collects the most common questions from our homepage, the overview pages, and the specialist subpages in one place. The compact FAQs intentionally remain on the respective detail pages. Here we additionally organize them as a landing page so prospective clients can quickly see which topics we really master in project kickoff, services, Delphi, C#, Layer-3, portals, modernization, data access, and platform strategy.
You can either jump directly to a topic block or, from below, switch to the in-depth subpage in each case. This keeps the page usable both as a quick entry point and as a structured FAQ hub.
Project kickoff
Project kickoff, architecture & collaboration
Questions about a sensible start, the initial assessment, and early architectural decisions.
Go directly to the answers
Services
Services at a glance
Questions about 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 selection, and the technical line across multiple expansion stages.
Go directly to the answers
Projects
Project snapshots and reference patterns
Questions about project size, operational responsibility, hosting, product logic, and systems built to carry over the long term.
Go directly to the answers
Enterprise software
Custom enterprise software & Layer-3
Questions about business viability, process logic, roles, data, and long-term extensibility.
Go directly to the answers
Delivery
Multiplatform with Delphi
Questions about Windows, macOS, Linux as well as later iOS and Android paths from a shared domain logic.
Go directly to the answers
Delivery
Services, REST servers & portals
Questions about portals, APIs, Windows and Linux services as part of the same domain architecture.
Go directly to the answers
Integration
Interfaces, data flows & target platforms
Questions about financial accounting, APIs, database refactoring, mapping, monitoring, and new target platforms.
Go directly to the answers
Delphi
Delphi for enterprise applications
Why Delphi can remain strong for established business logic, reports, and productive desktop processes.
Go directly to the answers
C#
C# for services & portals
Questions about REST, integrations, portals, backend services, and stable operations.
Go directly to the answers
Architecture
Layer-3 architecture
Questions about separating UI, business logic, and data access, and why that is directly relevant economically.
Go directly to the answers
Delphi team
Delphi developers from Freiburg
Questions about external support, taking over existing systems, and technical responsibility in established Delphi systems.
Jump directly to the answers
Support
Delphi Maintenance & Support
Questions about stabilization, further development, release reliability, and reducing single-person knowledge.
Jump directly to the answers
Modernization
Delphi Modernization
Questions about the refactoring path, risk, preserving business logic, and step-by-step renewal in live operation.
Jump directly to the answers
Data access
Replacing BDE
Questions about FireDAC, native drivers, SQL specifics, deployment, and database restructuring.
Jump directly to the answers
PostgreSQL
Delphi, PostgreSQL & FireDAC
Questions about PostgreSQL migration, native drivers, SQL behavior, and a calm data-access refactoring.
Jump directly to the answers
Delphi REST
Delphi REST API & REST Server
Questions about REST with Delphi, API scope, shared business logic, and clean server architecture.
Jump directly to the answers
Services
Windows & Linux Services
Questions about background services, scheduling, monitoring, restart behavior, and a clean operational setup.
Jump directly to the answers
Technology
Delphi Multiplatform
Questions about a shared codebase for Windows, macOS and Linux with controlled platform boundaries.
Jump directly to the answers
Server architecture
REST Server & Services
Questions about APIs, Windows and Linux services, server logic, monitoring, and operational responsibility.
Jump directly to the answers
Platform
Windows 11 ARM64
Questions about new hardware, native dependencies, drivers, builds, and rollout paths.
Jump 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 does technical orientation emerge, and how does an idea turn into a solid entry into a real project?
On the homepage, the first orientation questions usually come up: How do you start an initiative sensibly, which architecture questions should you clarify early, and when is modernization worth it instead of hectic redevelopment?
When is Delphi modernization worth it instead of a complete redevelopment?
If business logic, processes, and the data model are valuable, a controlled rebuild is often more economical than a fresh start with loss of functionality and high introduction risk.
Can the same business logic run for Windows, macOS and Linux?
Yes. Especially in Delphi projects, we plan shared business logic and separate UI, 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 the architecture for us and are not bolted on afterwards.
How does a typical project start?
Usually with a structured assessment of the current state: goals, existing systems, database, platforms, interfaces, and operational risks. From that, a realistic starting point can be defined.
Read more on the topic in depth
If you want to move from this FAQ to the more in-depth specialist page, you will find the broader context there, with architecture, examples, reasons for decisions, and related topics.
Services
Services at a glance
On the services page, the broadest follow-up questions usually arise: What exactly do we take on, how far does our technical responsibility extend, and how do modernization, integrations, operations, and further development interlock?
Especially with mature applications, the same business and technical questions often come up. 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 mature Delphi applications, analyze the existing system, data access, architecture, and special cases, and then continue building on that in a controlled manner.
Can REST servers, portals, and desktop clients emerge from a single initiative?
Yes. Especially for enterprise applications, we deliberately plan these components together so that the same business logic does not diverge into multiple bespoke solutions.
Is replacing a BDE possible without a complete replacement?
In many cases, yes. We gradually decouple data access, SQL, and deployment from the legacy structure and build a native, maintainable integration.
Do you also support operations and further development?
Yes. Release processes, hosting, root-cause analysis, database maintenance, and later extensions are part of our work.
Read more on the topic in depth
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 rationales, and related topics.
Technologies
Technology and architecture at a glance
This FAQ bundles the typical orientation questions around technology decisions: When is Delphi strong, when is C# the better building block, and how does a clean architecture bring multiple platforms, services, and clients together in a controlled way?
Technology decisions must fit the team, the domain, and operations. That is exactly why we do not clarify these questions in the abstract, but always against the concrete system.
When is Delphi a sensible choice compared to a complete replatforming?
Whenever mature domain logic, high-performance desktop processes, and multi-platform goals should be carried forward economically, rather than replacing substance carelessly.
When do you additionally use C#?
Primarily for portals, web backends, REST services, integrations, and service-oriented architecture components that can be tightly 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 changes manageable.
Do you consider new platforms such as Windows 11 ARM64 early on?
Yes. New target hardware and deployment paths are assessed early so they do not later turn into costly special projects.
Read more on the topic in depth
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 rationales, and related topics.
Projects
Project snapshots and reference patterns
Those who look at the project page usually want to understand what kind of initiatives we actually carry: one-off tools or longer-lived systems with operations, permission models, versions, integrations, and real ongoing development.
Many initiatives sound different at the beginning and yet share common patterns: mature domain logic, integrations, permissions, versions, operational questions, and long-term extensibility.
Do you work more on one-off standalone tools or on systems built to last?
The focus is on systems with runtime, responsibility, and ongoing development: enterprise applications, platforms, services, portals, and product logic.
Can existing products or internal systems be modernized in parallel?
Yes. Especially with long-evolved systems, we often plan an incremental evolution so that operations and modernization fit together.
Are hosting and technical operations part of your work?
Yes. Release management, hosting, monitoring, and operational responsibility flow into our project planning so that the finished solution is not only developed, but can also be operated 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, reasons for decisions, and related topics.
Enterprise software
Custom enterprise software & Layer-3
These questions typically come up when off-the-shelf software is no longer sufficient from a domain perspective and a company wants to know whether a custom system can really be built in an economically viable, maintainable, and extensible way.
Especially with custom enterprise software, it is not just about individual screens, but about roles, data, audit trails, and an architecture that remains adaptable later on.
Is custom enterprise software only useful for very large companies?
No. It pays off whenever off-the-shelf software maps processes only via detours, media breaks, or expensive special rules, and the actual 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 controllable.
Can you also engage with established legacy processes?
Yes. This is precisely where our work becomes strong, because we first make domain processes, existing data, and legacy logic readable, and then develop a viable target architecture from it.
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, reasons for decisions, and related topics.
View custom enterprise software & Layer-3 applications in detail
Performance
Multiplatform with Delphi
At this point, companies usually ask not only about a technical possibility, but about a robust strategy: Which parts remain shared, what must be handled in a platform-specific way, and how do you avoid ending up with an expensive parallel build?
Multiplatform only becomes valuable when the same domain logic remains coherently controlled across multiple target systems and platform specifics are made visible early.
With Delphi, can Windows as well as macOS, Linux, iOS, and Android be considered?
Yes. Depending on the project goal, we plan desktop targets, mobile front ends, and server-adjacent components along a shared domain line, instead of rebuilding each platform’s domain logic from scratch.
How do you prevent multiplatform projects from drifting apart in terms of domain logic?
Through a shared code and architecture strategy: business rules, the data model, and processes remain central, while platform-specific differences are deliberately encapsulated.
Are later mobile expansion stages still possible?
Yes. If architecture, services, and interfaces are prepared cleanly, iOS or Android targets can be integrated later in a much more controlled way.
Read the topic in detail
If you want to switch 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.
Service
Services, REST Servers & Portals
Especially here, permissions, data flows, logging, and business rules must stay together. That’s why we don’t treat the topic as a web add-on, but as a structured extension of the same application line.
Portals, REST APIs, and services only sell well if they do not sit alongside the core system in terms of business logic, but instead 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 operations logic are part of our recurring delivery patterns.
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 interfaces.
How do permissions, logging, and processes remain consistent between client and server?
By not hiding business rules in individual endpoints or UIs, but establishing a clear business core that client, portal, and service can use together.
Read the topic in detail
If you want to switch 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.
Integration
Interfaces, Data Flows & Platform Targets
These questions usually come up when data quality, traceability, and future platform changes become more important than the pure transfer of data from A to B.
Interfaces often look like side topics. In reality, they determine data quality, traceability, platform changes, and stable operations.
Can existing interfaces and data flows be renewed without a big bang?
Yes. In many projects, we gradually reorganize mappings, database paths, jobs, and integrations so that real processes can keep running.
Do you also handle financial accounting and third-party system integrations?
Yes. Especially accounting, APIs, CRM, warehouse, licensing logic, or industry-specific third-party systems must be integrated in a way that is well documented, observable, and controllable from a business perspective.
Do you consider platform targets such as Windows 11 ARM64 as part of such integration projects?
Yes. New target platforms, native dependencies, and future deployment paths need to be part of the same planning early on as interfaces and data-flow logic.
Read the topic in detail
If you want to move from this FAQ to the more in-depth expert page, you will find the broader context there, including 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 architecture decision today—and when other building blocks should sensibly complement it or take over.
With Delphi, in companies it is rarely about nostalgia, but about the question of how mature domain logic, desktop processes, and multiple target platforms can be carried forward economically and cleanly.
Why do you still deliberately use Delphi today?
Because in many enterprise applications, Delphi offers a strong combination of mature business logic, high-performance desktop processes, close-to-the-database operation, and controllable evolution.
Is Delphi only interesting for modernizing existing systems?
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-centered. In that case, we deliberately combine Delphi with C#, REST servers, or web building blocks—rather than forcing everything into a single tool.
Read the full topic
If you want to move from this FAQ to the more in-depth expert page, you will find the broader context there, including architecture, examples, decision rationales, and related topics.
C#
C# for services & portals
This FAQ is aimed at companies that do not see C# as an end in itself, but want to understand it as a strong building block for portals, APIs, integrations, and service-oriented architecture components.
For us, C# is especially strong when web portals, APIs, services, integrations, and a calm operational cut are the priority.
When is C# the better choice compared to Delphi?
Above all 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 exactly what makes sense: Delphi carries productive domain logic in the client, while C# cleanly complements it with services, portals, and API layers.
What are typical risks in C# projects?
Often, teams build something technically modern too quickly without cleanly slicing roles, domain logic, logging, deployment, and real operational questions early enough. That is exactly where we focus.
Read the full topic
If you want to move from this FAQ to the more in-depth expert page, you will find the broader context there, including architecture, examples, decision rationales, and related topics.
Architecture
Layer-3 architecture
Layer-3 is often explained in theoretical terms. In practice, however, this structure very directly determines whether new clients, services, tests, and extensions can connect cleanly—or end up diverging at high cost.
Layer-3 is not a textbook term, but a very practical answer to grown monoliths, contradictory extensions, and expensive coupling in day-to-day work.
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 fail directly against the monolith.
Is Layer-3 only useful for large projects?
No. Mid-sized systems in particular benefit greatly from it, because it allows later requirements to 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 are still hidden in UI code or directly in SQL special paths. Then the structure exists only on slides, not in the system.
Read more about the topic in detail
If you want to switch from this FAQ to the more in-depth technical page, you will find the broader context there, including architecture, examples, decision rationales, and related topics.
Delphi team
Delphi developers from Freiburg
With this request, it is rarely just about an available person. Usually the underlying question is whether a partner can reliably take over legacy code, domain logic, data access, and the technical direction.
When searching for Delphi developers, it is rarely just about available capacity. Most of the time, it is about the reliable takeover of existing systems, architecture, data access, and real technical responsibility.
When does an external Delphi developer make sense?
Especially when existing knowledge is missing, modernization has stalled, or an application needs to be evolved functionally without losing its substance.
Can you also step into grown Delphi applications?
Yes. That is exactly a focus: We analyze legacy code, database, deployment, special cases, and business processes, and then continue building on that in a controlled manner.
Is it only about programming, or also about technical direction?
It is explicitly also about direction. For us, good Delphi development includes architecture, data access, integrations, REST services, and real-world operations.
Read more about the topic in detail
If you want to switch from this FAQ to the more in-depth technical page, you will find the broader context there, including 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 a grown system can be evolved calmly again.
Maintenance for mature Delphi systems is more than bug fixing. It affects release reliability, data consistency, technical debt, and the question of how new requirements can fit smoothly into the existing system.
What belongs to good Delphi maintenance?
Error analysis, further development, database maintenance, release support, technical documentation, and an architecture that does not make new requirements more expensive every time.
Can support start even without a complete rebuild?
Yes. Often it begins with stabilization, making risks visible, and a prioritized list of technical and domain improvements.
How do you reduce dependence on individual know-how?
By documenting data paths, components, build steps, and critical domain logic in a structured way, and turning implicit knowledge back into comprehensible system logic.
Read the topic in detail
If you want to move from this FAQ to the more in-depth specialist page, you will find the broader context there with architecture, examples, decision rationales, and adjacent topics.
Modernization
Delphi modernization
These answers help especially where a legacy application is still strong from a domain perspective, but technically has accumulated too many points of friction to carry new requirements cleanly.
The critical point in modernization is rarely just the UI. In most cases it is about domain logic, data, dependencies, and a migration strategy that works in day-to-day operations.
Does an old Delphi application have to be completely replaced?
No. A controlled rebuild is often more sensible: renew data access, decouple logic, add services, and modernize UIs selectively.
How do you avoid breaking operations during modernization?
Through clear intermediate stages, clean interfaces, and a migration path in which old and new parts can coexist side by side in a controlled manner.
Can existing domain logic later be moved into services or portals as well?
Yes. That is exactly why we extract business logic from UI-adjacent legacy code and move it into a structure that clients, services, and APIs can use together.
Read the topic in detail
If you want to move from this FAQ to the more in-depth specialist page, you will find the broader context there with architecture, examples, decision rationales, and adjacent 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 deliberately address the topic a bit more broadly here.
The BDE is rarely just a single technical building block. It is tied to SQL, deployment, drivers, character sets, and historical side effects. That is why we treat the replacement as a modernization step, not as a component swap.
Is switching to FireDAC or native drivers possible without a complete rebuild?
Yes, often in stages. The key is to properly review SQL, data types, transactions, and special cases instead of just replacing components 1:1.
Why does BDE replacement almost always affect the database structure as well?
Because it often exposes old tables, indexes, character sets, and historically grown SQL paths that should be cleaned up as well for stability and performance.
What do you concretely gain from native database connectivity?
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 switch from this FAQ to the deeper technical page, you will find the broader context there with architecture, examples, decision rationales, and related topics.
PostgreSQL
Delphi, PostgreSQL & FireDAC
Anyone using PostgreSQL and BDE-Ablösung mit nativer Anbindung typically wants more than just a new component. Behind it is often the question of how to bring data access, SQL, deployment, and existing logic back into a sustainable line.
With PostgreSQL and BDE-Ablösung mit nativer Anbindung, it is not just about a new connection component. In most cases, it is 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 path, but not as a blind replacement. What matters is SQL behavior, data types, transactions, error paths, and the concrete existing system.
Can BDE, Paradox, or legacy SQL systems transition to PostgreSQL step by step?
Yes. In many cases, a controlled staged path is more economical than a hard cut, as long as the data model and domain logic are considered properly.
Read the topic in detail
If you want to switch from this FAQ to the deeper technical page, you will find the broader context there with architecture, examples, decision rationales, and related topics.
Delphi REST
Delphi REST API & REST server
This FAQ answers the typical fundamental question of whether REST with Delphi is just a technical add-on or a serious server strategy. What is decisive is always how cleanly client, rules, data, and operations are kept together.
REST with Delphi becomes strong when APIs do not sit detached next to the existing system, but instead carry permissions, business logic, data model, and operations cleanly along with them.
Can you build production-grade REST APIs with Delphi?
Yes. Especially when the same domain logic already lives in the existing Delphi system, a cleanly cut REST server is often more economical than a completely new parallel world.
When is a REST server worth it 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 domain perspective.
How do you keep the Delphi client and REST consistent?
Through an architecture in which business rules do not remain hidden in forms, but become jointly usable for client, API, and background processes.
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 rationale, and related topics.
Services
Windows & Linux services
With services, it is rarely just about a running process. More important are logging, observability, restart behavior, data consistency, and the domain 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 changes cleanly, and fit robustly into operations with logging, restart, and monitoring.
When does an enterprise application additionally need Windows or Linux services?
Whenever imports, exports, scheduling, synchronization, licensing 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 exactly what makes sense, because it prevents business logic, data model, and logging from diverging into multiple technical islands.
What is especially important for production services?
Clear error handling, observable states, restart safety, logging, deployment, and domain-consistent processing instead of silent background magic.
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 rationale, and related topics.
Technology
Delphi multi-platform
This FAQ sheds light on the technical side of the multi-platform strategy: codebase, packaging, system-level integration, release processes, and the question of when multiple clients really become economical.
Multi-platform only works cleanly when codebase, data model, platform differences, and deployment are planned deliberately. That is exactly where the real project value is created.
Can the same application really run on Windows, macOS and Linux?
Yes—if UI, business logic, platform specifics, and release processes are not mixed together but are structured cleanly.
What is the most common mistake in multiplatform projects?
Thinking too late about the file system, printing, signing, target platforms, packaging, and UI differences. Then multiplatform quickly becomes expensive and inconsistent.
Can services and APIs use the same business logic?
Yes. A sound architecture ensures that not every platform develops its own domain-specific special case.
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 rationale, and related topics.
Server architecture
REST Server & Services
If APIs and services only sound technically modern but are not cleanly cut along domain boundaries, 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 and bolted onto an existing desktop codebase. We deliberately plan these parts together.
When does an enterprise application additionally need a REST server?
As soon as multiple clients, portals, mobile access, external integrations, or decoupled processes are meant to use the same business logic in a controlled way.
Do you also support Windows and Linux services?
Yes. Background processes, scheduling, synchronization, exports, licensing services, and technical companion 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 shared, usable, and traceable.
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 rationale, and related topics.
Platform
Windows 11 ARM64
ARM64 affects many applications earlier than expected. This FAQ answers the typical questions around dependencies, testing, installers, and the business classification of new target hardware.
ARM64 is no longer an exotic side topic, but a real target platform. If you account for it early, you avoid later technical dead ends in deployment and with native dependencies.
Why should Windows 11 ARM64 already be considered today?
Because new hardware classes and mobile workplaces increasingly rely on it, and technical rework later becomes significantly more expensive than an early architectural decision.
What is particularly critical with Delphi and native dependencies on ARM64?
External libraries, database drivers, installers, setup processes, and tests on real target hardware in particular must be checked early.
Does ARM64 require a completely separate product?
Not necessarily. Often it is enough to prepare build and deployment paths cleanly and to decouple critical native dependencies in good time.
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.
Want to turn the FAQ into a concrete project discussion?
Then the next sensible step is not another collection of buzzwords, but a structured classification of your current landscape: What business logic exists, where does the current architecture slow you down, which interfaces are critical, and which expansion path is actually technically viable?