FAQ — Project start, architecture and collaboration

This page collects the most frequent questions from our homepage, the overview pages and the technical subpages in one place. The compact FAQs deliberately remain on the respective detail pages. Here we additionally arrange them as a landing page so that prospects can quickly see which topics we truly master in project initiation, services, Delphi, C#, Layer-3, portals, modernization, data access and platform strategy.

You can either jump directly to a topic block or navigate from below to the respective detailed page. This keeps the page usable both as a quick entry point and as a structured FAQ hub.

Project start

Project start, Architecture & Collaboration

Many initial questions are not about a single technology, but about the right starting point: What should be clarified first, how is technical orientation established, and how does an idea become a robust entry into a real project?

The homepage usually raises the first orientation questions: How should an initiative sensibly begin, which architectural questions should be clarified early, and when is modernization preferable to hasty redevelopment?

Services

Overview of services

The services page usually generates the broadest follow-up questions: What do we take on concretely, how far does our technical responsibility extend, and how do modernization, integrations, operations and ongoing development interact?

Especially with evolved applications the same business and technical questions often arise. We clarify these points early, before an initiative becomes a diffuse large-scale project.

Technologies

Technology and architecture overview

This FAQ bundles the typical orientation questions for technology decisions: when is Delphi a strong choice, when is C# the better building block, and how does a clean architecture bring multiple platforms, services and clients together in a controlled way?

Technological decisions must fit the team, the domain and the operational context. For that reason we do not discuss these questions abstractly, but always with the concrete system in mind.

Projects

Project snapshots and reference patterns

Those who look at the projects page usually want to understand which type of undertaking we actually take on: one-off tools or longer-lived systems with operation, permissions model, versions, integrations and genuine ongoing development.

Many projects appear different at first and yet share common patterns: evolved domain logic, integrations, permissions, versions, operational concerns and long-term extensibility.

Enterprise software

Custom enterprise software & Layer-3

These questions typically arise when standard software is no longer functionally sufficient and a company wants to know whether a custom system can be built that is economically viable, maintainable and extensible.

With custom enterprise software it is not just about individual screens, but about roles, data, approval paths and an architecture that remains adaptable later on.

Capabilities

Multiplatform with Delphi

At this point companies usually ask not only about a technical possibility, but about a reliable strategy: which parts remain shared, what must be handled platform-specifically and how to avoid creating an expensive parallel build?

Multiplatform becomes valuable only when the same domain logic remains controlled across multiple target systems and platform specifics are made visible early on.

Services

Services, REST-Server & Portale

Here, rights, data flows, logging and business rules must remain consistent. For that reason we treat the topic not as a web add-on but as an orderly extension of the same application lineage.

Portals, REST-APIs and services are only effective when they do not sit beside the core system functionally, but cleanly continue the same data and role logic.

Integration

Interfaces, data flows & platform objectives

These questions usually arise when data quality, traceability and future platform migrations become more important than the pure transfer of data from A to B.

Interfaces often appear as secondary topics. In reality they determine data quality, traceability, platform migration and stable operation.

Delphi

Delphi for enterprise applications

This addresses the fundamental question of when Delphi remains a deliberate architectural choice today and when other components should usefully complement or take over.

In companies, Delphi is rarely about nostalgia; it is about how established domain logic, desktop processes and multiple target platforms can be continued economically and cleanly.

C#

C# for Services & Portals

This FAQ is aimed at companies that view C# not as an end in itself but as a robust 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 stable operational profile are the primary focus.

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 break apart at high cost.

Layer-3 is not a textbook term but a practical response to grown monoliths, conflicting extensions and costly couplings in day-to-day operation.

Delphi team

Delphi developers from Freiburg

This request is rarely just about an available person. Usually the underlying question is whether a partner can reliably take over the existing codebase, domain logic, data access and the technical direction.

When searching for Delphi developers it’s rarely only about available capacity. Mostly it’s about a reliable takeover of the existing system, architecture, data access and real domain responsibility.

Support

Delphi maintenance & support

Maintenance often sounds smaller than it is. In practice it is about stable releases, visible risks, technical order and the question of how an evolved system can be further developed without disruption.

Maintenance for evolved Delphi systems is more than bug fixing. It concerns release stability, data consistency, technical debt and the question of how new requirements can be integrated into the existing system without disruption.

Modernization

Delphi Modernization

These answers are especially helpful where a legacy application remains strong functionally, but has accumulated too many technical bottlenecks to reliably carry new requirements.

The critical point in modernization is rarely just the UI. It is usually about domain logic, data, dependencies and a migration strategy that works in day-to-day operation.

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 here in a slightly broader scope.

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.

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 existing application logic can be brought back into a sustainable alignment.

With PostgreSQL and FireDAC it’s not just about a new connection component. Usually it implies a larger step toward more robust SQL, improved deployment and controllable data management.

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. The decisive factor is always how cleanly client, rules, data and operations are integrated.

REST with Delphi becomes strong when APIs are not detached alongside the existing system, but instead cleanly carry permissions, business logic, the data model and operations.

Services

Windows- & Linux-Services

With services it is rarely only about a running process. More important are logging, observability, restart behavior, data consistency and the functional question which parts belong in the background and which do not.

Background services are often the invisible core of a system. They must run reliably, process state transitions cleanly and fit robustly into operations with logging, restart capability and monitoring.

Technology

Delphi Multiplatform

This FAQ examines the technical side of the multiplatform strategy: codebase, packaging, system-level considerations, release processes and the question when multiple clients truly become economical.

Multiplatform only works cleanly when codebase, data model, platform differences and deployment are planned deliberately. That is exactly where the actual project value arises.

Server architecture

REST-Server & Services

If APIs and services only sound technically modern but are not cleanly separated in terms of business logic, they quickly become a problem. This FAQ places these decisions in context.

Many systems do not fail because of the API idea, but because server logic is later improvised onto an existing desktop install base. We plan these parts deliberately together.

Platform

Windows 11 ARM64

ARM64 affects many applications earlier than expected. This FAQ answers typical questions about dependencies, tests, installers and the economic assessment of new target hardware.

ARM64 is no longer an exotic side topic but a real target platform. Those who consider it early avoid later technical dead-ends in deployment and with native dependencies.