[ 01 // SOFTWARE · SYSTEMS · PRODUCTS ]

Software built to hold up beyond the demo.

EicDevCon develops web and mobile applications, integrations, and technical systems — deliberately architected and built for real-world operation.

System sketch: clients, services, identity and data Web and mobile clients talk to a shared service layer. That layer connects to an identity service for authentication and authorisation, and to persistent storage. Both run on jointly operated infrastructure. WEB / MOBILE API / SERVICES IDENTITY DATA INFRA [ SYSTEM SKETCH ]

WEB · MOBILE · IAM · INTEGRATION · INFRASTRUCTURE

[ 02 // FIELDS OF WORK ]

Where the engineering actually starts.

Six areas in which EicDevCon takes responsibility — described by the work involved, not by the stack.

  1. Software & integrations

    Business applications, interfaces and data flows between systems that were never designed for each other.

    Technologies: PHP · Python · TypeScript · PostgreSQL · Docker

  2. Web applications & platforms

    Server-rendered applications and platforms that stay maintainable, extensible and explainable years after they were built.

    Technologies: PHP · TypeScript · PostgreSQL · Docker · Linux

  3. Web Development

    Company, product and content websites – custom-built or based on an appropriate CMS.

    Technologies: PHP · TypeScript · Linux · Docker · Privacy by Design

  4. Mobile development

    Native applications for Android and iOS — including on-device storage, platform differences and release processes.

    Technologies: Kotlin · Swift · Android · iOS · Offline-first · Privacy by Design

  5. Identity & access management

    Authentication, authorisation and user management across systems that were never designed to interoperate.

    Technologies: Keycloak · OpenID Connect · OAuth 2.0 · SAML · LDAP · SCIM · Hochverfügbarkeit

  6. AI-Enabled Software Solutions

    From the initial idea to an operational AI solution: software architecture, machine learning, language processing and language models in one system.

    Technologies: Python · spaCy · Natural Language Processing · Machine Learning · OCR · Large Language Models · Local LLM

[ 03 // POSITIONING ]

Why EicDevCon?

Technical projects need more than working code. What counts are solutions that fit into existing structures, stay understandable, and remain manageable over the long term.

  • Experience in demanding IT environments

    Software development and integration that takes existing systems, technical dependencies, security and dependable operation into account.

  • Technical understanding beyond implementation

    Architecture, interfaces, data flows, operations and data protection are considered together — rather than each requirement being built in isolation.

  • Direct and transparent collaboration

    Short lines of communication, requirements assessed on their technical merits, and decisions that stay traceable without unnecessary organisational layers.

  • Sustainable, maintainable solutions

    The focus is on maintainable systems, architectures that can be reasoned about, and keeping technical dependencies to a minimum.

EicDevCon works with organisations where standard solutions fall short and technical decisions carry consequences well beyond the project.

[ 04 // ENGINEERING PROOF ]

The stack is a means, not a statement.

Technologies appear here in the context in which they are actually used.

Application engineering

Websites, business applications, interfaces and data flows – where technical requirements, domain logic and existing systems come together.

  • PHP Server-side applications and interfaces, including this website.
  • Python Data processing, automation and integration scripting.
  • TypeScript Type-safe application logic in the browser and in Node tooling.
  • PostgreSQL Relational storage with dependable consistency guarantees.

Mobile

Native applications for Android and iOS, including on-device data handling and release processes.

  • Kotlin Android applications including on-device storage.
  • Swift iOS applications following platform-native interaction patterns.
  • Android Platform-specific requirements, permissions and store processes.
  • iOS Review requirements, privacy declarations and release cycles.
  • Offline-first Applications that remain fully usable without a network connection.

Identity & access

Authentication, authorisation and user management across systems that were never designed to interoperate.

  • Keycloak Central authentication, realms, clients and role models.
  • OpenID Connect Standardised sign-in for web and mobile clients.
  • OAuth 2.0 Delegated authorisation between services.
  • SAML Integration with existing enterprise identity providers.
  • LDAP Directory services as the system of record for users and groups.
  • SCIM Automated provisioning and deprovisioning of user accounts.

AI engineering & applied AI

Machine learning, language processing and language models as part of a business application – not as a demonstration beside it.

  • spaCy Language analysis and entity recognition in unstructured text.
  • Natural Language Processing Making linguistic structure usable where fixed rules would be too rigid.
  • Machine Learning Trainable classification where patterns cannot be enumerated exhaustively.
  • OCR Text recognition in scans when a document carries no usable text layer.
  • Large Language Models Semantic understanding where rules and classification reach their limits.
  • Local LLM Running language models inside your own infrastructure, for example via Ollama or LM Studio.

Platform & operations

Runtime, operations and availability – the layer where architectural decisions show their cost first.

  • Linux Operating system foundation for application and database services.
  • Docker Reproducible runtime environments for development and operations.
  • Kubernetes Orchestration where several services are operated together.
  • Hochverfügbarkeit Failure behaviour, redundancy and operational boundaries – settled before the incident.
  • Privacy by Design Data minimisation as an architectural decision, not a later setting.

See all competency areas

[ 05 // PROJECTS ]

Decisions need context.

Case studies show the starting situation, ownership, system boundaries and the reasoning behind each decision.

Case study

AI-Enabled Document Analysis and Process Automation

A hybrid pipeline of text recognition, rules, language processing, classification and language models – delivered as a custom business application.

Technologies: Python · OCR · Natural Language Processing · spaCy · Machine Learning · Large Language Models · Local LLM

Read the case study

Hybrid AI processing pipeline

A document passes through nine consecutive stages: PDF or scan, text recognition, rule-based analysis, language processing, entity recognition, classification, language model analysis, domain logic and structured result. The result is then handed to the business application through an interface.

  1. 01 PDF / SCAN
  2. 02 OCR
  3. 03 RULES
  4. 04 NLP
  5. 05 ENTITIES
  6. 06 CLASSIFICATION
  7. 07 LLM
  8. 08 DOMAIN LOGIC
  9. 09 RESULT

APPLICATION · API

See all projects

[ 06 // PRODUCTS ]

We don't only build for others.

Running our own products keeps decisions about architecture, data handling and operations visible across a full lifecycle.

AuraHarmony

EicDevCon's own mobile product for Android and iOS — built natively, with all data kept on the device.

Technologies: Kotlin · Swift · Android · iOS · Offline-first · Privacy by Design

View this product

Offline-first architecture of AuraHarmony The Android and iOS applications share a common domain model. That model reads and writes local on-device storage. There is no server synchronisation: all data stays within the device boundary. ANDROID / KOTLIN IOS / SWIFT DOMAIN MODEL LOCAL STORAGE [ DEVICE BOUNDARY ] NO BACKEND · NO SYNC
All usage data stays on the device. There is no synchronisation with a server.

See all products

[ 07 // INSIGHTS ]

Notes from technical practice.

Articles about questions that actually had to be decided in projects.

Identity & Access Management

Running Keycloak in high availability

High availability in Keycloak is an architectural decision, not a configuration switch. What actually has to be decided.

Mobile & Products

Offline-first is a data model decision

Offline capability cannot be retrofitted. It is decided where you settle who owns a record and when that record is valid.

See all articles

[ 08 // HOW WE WORK ]

System boundaries first. Then the code.

Four steps that come before the first line of code — and continue after it.

  1. Understand the starting situation

    Which systems already exist, who operates them, and which assumptions have never actually been verified?

  2. Assess dependencies and risks

    What happens on failure, under load, or when data quality degrades? These questions belong before the architecture.

  3. Decide the architecture

    System boundaries, ownership and technology decisions are reasoned through and written down.

  4. Build it and keep developing it

    Software gets built, operated and adapted. Maintainability is a result of the first three steps.

[ 09 // CONTACT ]

A problem is easier to plan once it becomes concrete.

The starting situation, existing systems, timeframe and open technical questions are enough for a first dependable assessment.