An engineering practice built around clarity, not noise

HES & CAR GmbH is an IT company working on custom software, web platforms, cloud architecture and integration work. This page describes how we think about technology and how we prefer to work — nothing more, nothing embellished.

01 — Company overview

What the company does

HES & CAR GmbH designs, builds and maintains software systems. The work spans backend services and data models, browser-based applications, cloud environments that run them, and the integrations that connect these systems to the tools an organisation already uses.

Engagements typically begin with an existing problem rather than an existing specification: a manual process that no longer scales, a legacy system that is expensive to change, or a product idea that needs a technical shape before it can be costed. Our role is to translate that situation into a system that can be built, operated and changed later.

A quiet minimal studio workspace with a long graphite table, closed laptops and printed system architecture diagrams — Fig. A — Working environment: documents, diagrams, and deliberate quiet.

02 — Purpose

Our approach to technology

Technology choices are decisions with a cost attached. A framework, a database, a queue or a hosting model each carries operational weight that someone will carry for years. We prefer boring, well-documented components used carefully over novel components used enthusiastically.

We also treat software as something that is read far more often than it is written. A system that is easy to reason about is cheaper to extend, safer to modify under pressure, and easier to hand over. That preference shapes how we structure code, write documentation and design interfaces between components.

The goal is not the most advanced possible system. It is the simplest system that genuinely solves the problem and can survive being changed.

03 — Engineering principles

Principles we apply to day-to-day work

Understand before building

Requirements are rarely complete on first contact. We ask about edge cases, data ownership and failure behaviour early, because those details decide the architecture.

Small, reversible steps

Work is delivered in increments that can be reviewed and, if necessary, undone. Large irreversible migrations are planned explicitly, never improvised.

Explicit boundaries

Modules and services have defined responsibilities and defined interfaces. Shared mutable state across boundaries is treated as a design problem.

Automate what repeats

Builds, tests, deployments and environment setup belong in scripts and pipelines rather than in individual memory.

Observability from the start

Logging, metrics and error reporting are part of the initial build, not a later addition after an incident.

Documentation as a deliverable

Architecture notes, runbooks and decision records are written alongside the code, so the system is understandable without its original authors.

Two engineers reviewing a hand-drawn system architecture diagram on a whiteboard — Fig. B — Architecture review: shared understanding before implementation.

04 — Collaboration

How we work with the people we build for

We work in the open. Progress, obstacles and trade-offs are shared as they happen, in plain language, without waiting for a milestone to make the news comfortable.

Decisions are documented with their reasoning, so a choice made in month one still makes sense in month nine. Where a client team has its own engineers, we plan for joint review and shared ownership rather than a closed handover at the end.

We also say when something is outside our judgement. A clear "we would need to investigate that" is more useful than a confident guess.

05 — Quality

Quality and maintainability

Overhead view of a mechanical keyboard beside a notebook with hand-drawn user flow and data flow diagrams — Fig. C — Flows sketched on paper before they become code.

Quality, for us, is measured by how a system behaves after release: whether failures are visible, whether data stays consistent, whether a new developer can make a change without fear. Tests, reviews and type safety are the tools; predictable behaviour is the outcome we are aiming at.

Automated tests cover the logic that matters most — business rules, data transformations, boundary conditions — rather than chasing a coverage number. Continuous integration runs them on every change, so regressions surface while the context is still fresh.

Maintainability is planned deliberately: dependency updates, configuration kept out of code, migrations that can run repeatedly without damage, and environments that can be rebuilt from scratch. We treat security as part of the same discipline — least-privilege access, validated input, secrets stored outside the repository, and careful handling of personal data.

This page describes intent and method. It intentionally contains no claims about specific clients, certifications or measured results.