Kos GmbH — Information technology
We design, build and operate custom software, web applications, cloud platforms and integrations for organisations whose systems have to keep running long after the first release.
Illustrative stock photography — not a Kos GmbH facility
Introduction
Kos GmbH is an IT company working on custom software, web applications, cloud infrastructure and systems integration.
Our work usually begins where a process has outgrown the tools supporting it: data spread across spreadsheets, manual steps repeated daily, systems that cannot exchange information, or an application that has become risky to change. We treat those as engineering problems with concrete constraints, not as opportunities to introduce as much technology as possible.
Everything described on this website is a proposed service offering presented for review. We do not publish client names, case studies or performance figures, and the project descriptions further down this page are clearly marked as hypothetical examples.
Enquiries are handled by email at [email protected].
Capabilities
Six areas of technical work that combine differently depending on the system in question.
01
Backend services, domain models and user interfaces built as one coherent system rather than a set of disconnected parts.
02
Relational schema design, migrations, indexing strategy, caching layers and reporting queries that stay predictable as volume grows.
03
Containerised environments, infrastructure as code, automated pipelines and reproducible release procedures.
04
HTTP and event-driven interfaces documented as versioned contracts so integrating teams can build against them independently.
05
Structured logging, metrics and traces defined during development, not retrofitted after an incident.
06
Incremental replacement of ageing components, with behaviour preserved through characterisation tests.
Discipline 01
Applications shaped around an existing process instead of forcing the process to fit a product.
We start from the workflow: who acts, what they decide, what data they need in front of them and which rules must never be broken. That becomes a domain model, a set of interfaces and a plan for delivering usable slices early.
Typical work includes internal operational tools, planning and scheduling systems, document and approval workflows, calculation engines with auditable results, and reporting layers over data that currently only exists in exports.
Deliverables are the running application, its source code and infrastructure definitions, automated tests, and documentation covering setup, configuration and operational procedures.
Discipline 02
Browser-based systems that behave predictably on slow connections and small screens.
We build responsive interfaces with semantic markup, keyboard operability and sufficient colour contrast, and we test them at mobile, tablet and desktop widths rather than assuming a single viewport.
On the server side this covers authentication and session handling, role and permission models, form and file handling, background jobs, and rendering strategies chosen so that meaningful content reaches crawlers and low-powered devices.
Performance work is measured: payload budgets, image sizing, caching headers and query profiling, verified before release rather than estimated afterwards.
Discipline 03
Environments described in code, so they can be rebuilt rather than remembered.
Networking, compute, storage and access rules defined in version-controlled templates, reviewed like application code and applied through a pipeline.
Build, test, security scan and deploy stages that run on every change, with identical steps across staging and production.
Metrics, log aggregation, alert thresholds tied to user-visible symptoms, tested backups and documented restore procedures.
Right-sizing, autoscaling rules and cost visibility, so infrastructure spend tracks actual load.
Discipline 04
Most operational friction comes from systems that hold overlapping data and never speak to each other.
We define which system owns each piece of data, then move it deliberately: scheduled synchronisation, event-driven messaging, or a documented API in front of a system that never had one. Failure handling is part of the design — retries with backoff, dead letter handling, idempotent processing and a review screen for records that cannot be reconciled automatically.
Automation work removes manual relay steps: file transfers, re-keying between applications, notification chains and report assembly. Each automated step keeps an audit record, so a disputed outcome can be traced back to the data that produced it.
Discipline 05
Security treated as a property of the design, verified continuously rather than declared once.
Authentication flows, session and token handling, least-privilege role models, and authorisation checks enforced on the server for every request.
Encryption in transit and at rest, careful handling of secrets, data minimisation, and retention rules implemented in the system rather than left to policy alone.
Validation at trust boundaries, parameterised queries, output encoding, and automated scanning of third-party dependencies for known vulnerabilities.
Security-relevant logging, alerting on abnormal patterns, a documented patching path, and an agreed procedure for handling suspected incidents.
Delivery
Six stages, each producing something you can read, run or review.
01
We map the business process the software serves, the systems it must exchange data with, and the constraints that are non-negotiable. The output is a written problem statement and a shortlist of options with their trade-offs.
02
We propose a technical design: service boundaries, data model, integration points, hosting model and security posture. Scope is broken into increments that each produce something reviewable.
03
Work proceeds in short cycles. Each increment is code-reviewed, covered by automated tests and deployed to a shared environment where you can inspect it directly.
04
Functional testing, integration testing against real interfaces, performance checks under expected load, and a security review of authentication, authorisation and data handling.
05
Automated deployment, database migrations rehearsed in advance, a documented rollback path, and monitoring in place before traffic is switched.
06
Dependency and security updates, monitoring review, backlog refinement and performance tuning, planned with you at a cadence that matches the system's importance.
Software is finished when someone else can change it without fear.
Code is written to be understood by the next engineer who opens it. Simple structures are preferred over abstractions that only pay off hypothetically.
Automated tests are written as statements about expected behaviour, so a failing test explains what broke rather than merely that something did.
If a step must happen on every release, it belongs in a pipeline rather than in a document that people are asked to remember.
Architectural choices are recorded with their context and alternatives, so future changes start from reasoning instead of guesswork.
Frequent modest releases reduce risk and make the cause of a regression easy to locate.
Documentation, environment setup and runbooks are produced during the work, so your team is never dependent on a single supplier to operate the system.
Examples
The following scenarios are hypothetical illustrations written to show how we approach common problems. They are not descriptions of completed projects or clients.
Illustrative example
A distribution business tracks orders across several shared spreadsheets. A web application consolidates them into a single database with role-based access, validation rules and an audit trail, while an export keeps existing accounting routines working during the transition.
Illustrative example
An online shop and an ERP system hold conflicting stock figures. A synchronisation service reconciles them through a queue, retries failed messages and surfaces unresolved conflicts on an internal review screen instead of failing silently.
Illustrative example
A long-running internal application is packaged into containers, its configuration extracted into environment variables, and its deployment automated. Characterisation tests capture existing behaviour before any refactoring begins.
Illustrative example
A partner needs programmatic access to data held in an internal system. A documented, versioned and rate-limited API is placed in front of it, with scoped credentials and per-client usage logging.
Working together
Predictable rhythm, written decisions, no surprises at the end of a sprint.
Each engagement has one point of contact on our side and one on yours. Progress is visible in a shared backlog, and every increment is deployed where you can try it rather than described in a status report.
We keep a written record of decisions, open questions and known risks. When a trade-off appears — a faster path with a maintenance cost, or a slower one that ages better — we present both with a recommendation instead of choosing quietly.
Time zones, working languages, review expectations and escalation paths are agreed at the start. Written English is used for documentation and specifications.
Questions
Answers are shown in full; nothing is hidden behind interactive controls.
Business applications, internal tools, web platforms, integration services and the infrastructure that runs them. The common thread is software that supports an operational process and is expected to run for years.
Through a discovery phase that produces a written problem statement, a technical approach and an increment plan. Scope is expressed as outcomes with acceptance criteria, so both sides can tell when something is finished.
Technology is selected per project from mainstream, well-supported options, based on the problem, the hosting constraints and the skills of the team that will maintain the result. We do not commit to a single stack in advance of understanding the requirement.
Ownership arrangements are agreed in the contract before work begins. Our default proposal is that you own the source code, infrastructure definitions and documentation, held in repositories under your control.
Automated unit, integration and end-to-end tests run in a pipeline on every change, together with code review, dependency scanning and a review of authentication, authorisation and data handling before release.
A maintenance arrangement can cover dependency and security updates, monitoring review, incident response and a planned improvement backlog. The scope and cadence are agreed rather than assumed.
Yes. Work can be organised as a joint team with shared repositories, shared review standards and a common definition of done, or as a self-contained workstream with defined interfaces.
By email. Write to [email protected] with a description of the system, the outcome you need and any fixed constraints. The service descriptions on this website are proposed offerings presented for review.
Contact
Kos GmbH
Enquiries are received by email. Please include the system involved, the outcome you need and any fixed constraints such as hosting requirements or existing integrations. No postal address, telephone number or response-time commitment is published on this website.