Questions and Answers
Central FAQ at a glance
Who is responsible for data protection in the company?
Responsibility remains with company management. Tasks can be delegated, but responsibility for decisions, priorities, and the use of suitable service providers cannot.
When is a data protection officer useful?
That depends on the type and scope of processing, on legal obligations, and on the level of internal organization. Even where there is no formal obligation, external support can be useful to anchor data protection in a structured way.
How extensive does ISO 9001 documentation need to be?
As extensive as necessary, but as lean as possible. Documentation should map processes, roles, and evidence—not cover the organization in text.
What is the benefit of an internal audit if not everything is perfect yet?
That is precisely when an internal audit is valuable. It shows where rules, evidence, or responsibilities are still unclear and which measures will have an effect first.
What is specifically checked in an internet audit?
Typical areas are tracking and cookie logic, forms, newsletter flows, external services, hosting, update maintenance, roles, redirects, the security baseline, and the data-protection classification of these items.
Is data protection only a legal topic?
No. Data protection always also has organizational and technical aspects. Without clean processes and without technical assessment, legal requirements remain difficult to implement in day-to-day operations.
How quickly can a robust status be established?
That depends on the current state. In most cases, an initial structured working status is achievable significantly faster than a complete final version. The decisive factor is to prioritize the topics sensibly.
How are data protection, QM, and website operations related?
They share the same basic question: Which processes are controlled, documented, reviewed, and improved—and how? That is exactly why many topics can be handled better together than in isolation.
Data access
BDE replacement
The BDE is rarely just an old driver. It is usually tied to historical SQL logic, database assumptions, and deployment paths. That is precisely why we deliberately address the topic a bit more broadly here.
The BDE is rarely just a single technical component. It is tied to SQL, deployment, drivers, character sets, and historical side effects. That is why we treat the replacement as a modernization step rather than a component swap.
Is a switch to FireDAC or native drivers possible without a complete rebuild?
Yes, often in stages. What matters is to properly review SQL, data types, transactions, and special cases instead of simply replacing components 1:1.
Why does BDE replacement almost always also affect the database structure?
Because this often reveals 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 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, including 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 strong building block for portals, APIs, integrations, and service-oriented architecture components.
For us, C# is particularly strong when web portals, APIs, services, integrations, and a calm operational setup are the focus.
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 exact combination is often sensible: Delphi carries productive business logic in the client, while C# cleanly complements services, portals, and API layers.
What are typical risks in C# projects?
Too often, a technically modern solution is built too quickly, without cleanly slicing roles, business logic, logging, deployment, and real operational questions early enough. That is exactly where we come in.
Read more on 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 with 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 systems, business logic, data access, and the technical direction.
When looking for Delphi developers, it is rarely just about available capacity. Usually, it is about a reliable takeover of existing systems, architecture, data access, and real subject-matter responsibility.
When does an external Delphi developer make sense?
Above all, when domain knowledge is missing, modernization has stalled, or an application needs to be further developed 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 way.
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 on 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 with architecture, examples, decision rationales, and related topics.
Modernization
Delphi modernization
These answers are most helpful where a legacy application is still strong from a business perspective, but has accumulated too many technical bottlenecks to support new requirements cleanly.
The critical point in modernization is rarely just the user interface. In most cases, it is about business logic, data, dependencies, and a migration strategy that works in day-to-day operations.
Does an old Delphi application have to be replaced completely?
No. Often a controlled refactoring is the better option: renew data access, decouple logic, add services, and selectively modernize user interfaces.
How do you avoid operational disruption during modernization?
With 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 business logic later be moved into services or portals?
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 more on the topic in detail
If you want to move from this FAQ to the more in-depth subject page, you will find the broader context there with architecture, examples, reasons for decisions, and related topics.
Technology
Delphi Multiplatform
This FAQ highlights the technical side of the multiplatform strategy: codebase, packaging, system proximity, release processes, and the question of when multiple clients really become economical.
Multiplatform only works cleanly when codebase, data model, platform differences, and deployment are planned deliberately. That is where the real project value is created.
Can the same application really run on Windows, macOS and Linux?
Yes, if user interface, business logic, platform specifics, and release processes are not mixed together, but structured cleanly.
What is the most common mistake in multiplatform projects?
Thinking too late about filesystem, 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. Good architecture ensures that not every platform develops its own special-case business path.
Read more on the topic in detail
If you want to move from this FAQ to the more in-depth subject page, you will find the broader context there with architecture, examples, reasons for decisions, 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. Behind it is often the question of how to bring data access, SQL, deployment, and existing logic back onto a sustainable track.
With PostgreSQL and BDE-Ablösung mit nativer Anbindung it is not just about a new connection component. In most cases, there is a larger step behind it 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 are SQL behavior, data types, transactions, error paths, and the concrete existing landscape.
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 cutover, as long as the data model and domain logic are cleanly taken into account.
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, with architecture, examples, decision rationale, and adjacent topics.
Delphi REST
Delphi REST API & REST server
This FAQ answers the typical fundamental question of whether REST with Delphi is merely 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 becomes strong when APIs do not sit detached alongside the existing landscape, but instead cleanly carry along permissions, business logic, data model, and operations.
Can you build production-grade REST APIs with Delphi?
Yes. Especially when the same domain logic already lives in the existing Delphi landscape, 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 are supposed to use the same rules in a controlled way, and direct SQL access becomes too risky from a domain perspective.
How do you keep 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 expert page, you will find the broader context there, with architecture, examples, decision rationale, and adjacent 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 meaningfully complement it or take over.
With Delphi in companies, it is rarely about nostalgia, but about the question of how grown domain logic, desktop processes, and multiple target platforms can be carried forward in a clean and economical way.
Why do you still deliberately rely on Delphi today?
Because Delphi provides a strong combination in many enterprise applications: mature business logic, high-performance desktop processes, close-to-database execution, and evolvable, controllable further development.
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 across multiple platforms are important.
Where are the limits of Delphi?
Mainly where an initiative is primarily portal-, service-, or cloud-centric. In that case, we deliberately combine Delphi with C#, REST servers, or web building blocks—instead of forcing everything into a single tool.
Read more on this topic in depth
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 rationale, and adjacent 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 mature 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 into the existing system without disruption.
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 without a complete rebuild?
Yes. It often begins with stabilization, making risks visible, and a prioritized list of technical and domain improvements.
How do you reduce dependency 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 more on this topic in depth
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 rationale, and adjacent 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 can connect smoothly—or drift apart at high cost.
Layer-3 is not a textbook term, but a very practical answer to mature monoliths, contradictory extensions, and costly couplings 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. Medium-sized systems in particular benefit strongly 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 continue to be hidden in UI code or directly in special-case SQL paths. Then the structure exists only on slides, not in the system.
Read the topic in detail
If you want to move from this FAQ to the in-depth technical 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 we usually see the broadest follow-up questions: What exactly do we take on, how far does our technical responsibility extend, and how do modernization, integrations, operations, and further development fit together?
Especially with evolved applications, the same functional 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 evolved Delphi applications, analyze the existing state, data access, architecture, and edge cases, and then build on that in a controlled manner.
Can REST servers, portals, and desktop clients come out of a single initiative?
Yes. Especially for enterprise applications, we deliberately plan these building blocks together so that the same business logic does not drift apart across multiple special-case solutions.
Is a BDE replacement possible even without a complete swap?
In many cases, yes. We decouple 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 work profile.
Read the topic in detail
If you want to move from this FAQ to the in-depth technical page, you will find the broader context there, with architecture, examples, reasons for decisions, and related topics.
Service
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 platform-specifically, and how does this avoid becoming 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 macOS, Linux, iOS and Android also be considered alongside Windows?
Yes. Depending on the project goal, we plan desktop targets, mobile front ends, and server-adjacent components from a shared functional line, instead of rebuilding each platform’s functional layer from scratch.
How do you prevent multi-platform projects from drifting apart functionally?
Through a shared code and architecture strategy: business rules, 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 move from this FAQ to the more in-depth specialist page, you will find the broader context there, with architecture, examples, decision rationales, and related topics.
Projects
Project images and reference patterns
Anyone looking at the project page usually wants to understand what kind of initiatives we actually carry: one-off tools or longer-lived systems with operations, permission concepts, versions, integrations, and real ongoing development.
Many initiatives sound different at first and yet share common patterns: evolved business logic, integrations, permissions, versions, operational considerations, 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 continued 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 a stepwise evolution so that operations and modernization fit together.
Are hosting and technical operations part of your work?
Yes. Release, hosting, monitoring, and operational responsibility flow into our project planning so 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 specialist page, you will find the broader context there, 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 structured from a functional perspective, they quickly become a problem. This FAQ classifies exactly those decisions.
Many systems do not fail because of the API idea, but because server logic is later improvised and bolted onto an existing desktop base. We deliberately plan these parts together.
When does an enterprise application additionally need a REST server?
As soon as multiple clients, portals, mobile access paths, 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 part of our typical scope.
How is functional consistency maintained between client, REST and service?
Through an architecture in which business rules are not hidden in individual user interfaces, but remain shared, reusable, and traceable.
Read the topic in detail
If you want to move from this FAQ to the more in-depth specialist page, you will find the broader context there, including architecture, examples, decision rationales, and adjacent topics.
Service
Services, REST servers & portals
This is precisely where permissions, data flows, logging, and business rules have to 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 work well if, functionally, they don’t sit alongside the core system, 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 user interfaces.
How do permissions, logging, and processes remain consistent between client and server?
By not hiding business rules in individual endpoints or UIs, but establishing a clear functional 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 specialist page, you will find the broader context there, including architecture, examples, decision rationales, and adjacent topics.
Technologies
Technology and architecture at a glance
This FAQ bundles the typical orientation questions around technology choices: 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 have to fit the team, the business domain, and operations. That’s exactly why we don’t clarify these questions in the abstract, but always against the concrete system.
When does Delphi make sense compared to a complete replatforming?
Whenever evolved domain logic, high-performance desktop processes, and multi-platform targets need to be carried forward economically—rather than replacing substance carelessly.
When do you additionally use C#?
Mainly for portals, web backends, REST services, integrations, and service-oriented architecture components that can interlock well 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 evaluated early so they do not later turn into costly special projects.
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—covering architecture, examples, decision rationales, and related topics.
Enterprise software
Custom enterprise software & Layer-3
These questions typically come up when off-the-shelf software no longer meets domain requirements and a company wants to know whether a custom system can truly be built in an economical, maintainable, and extensible way.
Especially with custom enterprise software, it is not just about individual screens, but about roles, data, validation paths, and an architecture that remains adaptable later on as well.
Is custom enterprise software only sensible for very large companies?
No. It pays off whenever off-the-shelf software can only map processes 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 for enterprise applications?
Because only the separation of UI, business logic, and data access ensures that reporting, new clients, services, and future extensions remain economically controllable.
Can you also get involved in evolved legacy processes?
Yes. Especially then our work is strong—because we first make domain processes, existing data, and legacy logic readable, and from that develop a viable target architecture.
Read the topic in detail
If you want to move from this FAQ to the more in-depth specialist page, you will find the broader context there—covering architecture, examples, decision rationales, and related topics.
View custom enterprise software & Layer-3 applications in detail
Platform
Windows 11 ARM64
ARM64 affects many applications sooner than expected. This FAQ answers the typical questions around dependencies, testing, installers, and the economic classification of new target hardware.
ARM64 is no longer an exotic side topic, but a real target platform. Those who factor it in early 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?
Above all, external libraries, database drivers, installers, setup processes, and testing on real target hardware must be checked early.
Does a completely separate product have to be created for ARM64?
Not necessarily. Often it is sufficient 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 switch from this FAQ to the more in-depth technical page, you will find the broader context there with architecture, examples, reasons for decisions, and adjacent 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 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 calmly, 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, 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 exactly what makes sense, because business logic, data model, and logging then do not drift apart into multiple technical islands.
What is particularly important for production services?
Clear error handling, observable states, restart safety, logging, deployment, and functionally consistent processing instead of silent background magic.
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 with architecture, examples, reasons for decisions, and adjacent topics.