About us
A company organised around engineering judgement.
Garden Delights GmbH builds and maintains software systems for organisations that depend on them operationally. We work in small teams, keep our reasoning written down, and hand over systems that other engineers can understand.
01Company overview
Who we are
Garden Delights GmbH is a software engineering company. We design, build, integrate and maintain applications, cloud platforms and data systems. Our engagements range from a single well-scoped application to long-running work on a system that has to keep operating while it evolves.
We do not separate analysis from implementation. The engineers responsible for a system take part in defining it, which keeps the architecture aligned with the problem and shortens the distance between a question and an accurate answer.
02 — Mission
Mission
To build software that solves a defined problem correctly and remains maintainable afterwards — clear in structure, covered by tests, documented well enough for a new engineer to continue the work.
03 — Vision
Vision
A working relationship in which technology stops being an obstacle: systems that our clients understand, can operate independently and can change with confidence as their organisation changes.
04Values
Values we apply daily
Clarity
We write in plain language: requirements, estimates, risks and status.
Rigour
Assumptions are tested. Decisions are recorded with their trade-offs.
Restraint
The simplest system that satisfies the requirement is the one we build.
Ownership
Responsibility for a component does not end when the code is merged.
Continuity
Documentation and tests so the system outlives individual contributors.
Respect
For domain knowledge, for end users and for the constraints we are given.
05Working philosophy
How we approach the work
We start from the operating reality rather than a feature list. Before writing code we want to know which decisions the software supports, who takes them, and what happens when the system is unavailable. That understanding determines the architecture more than any technology preference.
Work proceeds in short iterations with visible output. Scope is negotiated against evidence: if an assumption fails during implementation, the plan changes and the reason is recorded. We prefer to remove a feature that is not earning its complexity rather than carry it indefinitely.
We build for handover from the first commit. Environments are reproducible, secrets are externalised, and the setup instructions are tested by someone who did not write them.
06Software quality
Our approach to software quality
Tests as specification
Automated tests describe intended behaviour and run on every change, so regressions surface in minutes rather than in production.
Review before merge
Every change is read by another engineer. Review covers correctness, readability and the effect on the surrounding system.
Observability by default
Structured logs, metrics and traces are added while a feature is written, so failures can be diagnosed with data.
Continuous maintenance
Dependencies, migrations and technical debt are handled on a schedule instead of accumulating into a rewrite.
07Communication
Our approach to communication
Communication is part of the deliverable. We agree at the start who decides what, how often we meet, and where written decisions live. Status is reported against agreed acceptance criteria, including what did not go to plan.
We ask direct questions early instead of guessing, and we prefer a short written note over an undocumented conversation. When we disagree with a proposed direction, we explain why and offer an alternative rather than implementing something we consider unworkable.
- Single shared source of truth
- Decisions recorded in writing
- Explicit acceptance criteria
- Early escalation of risk