P-01
Write down the decision
Architectural choices are recorded with their context, the alternatives considered and the trade-off accepted. Teams that inherit the system can understand why it looks the way it does.
01About us
An engineering company,described accurately
Calla Flower GmbH designs, builds and maintains custom software for organisations that depend on their systems every working day. We work as an engineering partner: reading the existing landscape, agreeing on a target state, and delivering it in verifiable steps.
Company overview
Calla Flower GmbH is a technology company focused on custom software development, web application engineering, cloud solutions, system integration and long-term technical support. Our work usually begins where an organisation has outgrown a manual process, a spreadsheet, or a system that was built for a smaller scale.
Engagements are structured around a defined scope, a shared backlog and regular working sessions with the people who will use and operate the software. We prefer to work close to the client's domain experts rather than at arm's length through documents alone.
Mission
To make software a dependable part of an organisation's operations — understandable in its design, predictable in its behaviour, and maintainable by the people responsible for it after delivery.
We measure our work by whether a client can keep running and evolving the system with confidence, not by how much of it only we can understand.
02Working principles
Six rules we apply on every engagement
P-02
Small, reversible steps
Work is delivered in increments that can be reviewed, released and rolled back independently. Long-lived branches and big-bang releases are avoided wherever the domain allows.
P-03
Automate the repeatable
Builds, tests, migrations and deployments belong in pipelines, not in someone's terminal history. Manual steps are documented while they still exist and removed when they can be.
P-04
Own the interfaces
Contracts between services, teams and third parties are defined explicitly, versioned, and validated in automated checks before they reach production.
P-05
Design for the operator
Logs, metrics, traces and alerts are part of the feature, not a follow-up ticket. A system that cannot be observed cannot be supported responsibly.
P-06
Say what is uncertain
Estimates come with assumptions and known unknowns. When a plan stops matching reality, we raise it early rather than absorb it silently.
03Approach to technology projects
Understand the system before changing it
A project starts with a review of what already exists: data models, integrations, deployment topology, operational pain points and the constraints that cannot be negotiated. Only then do we propose a target architecture and a sequence for reaching it.
- DISCOVERY
Workshops with domain experts, review of current systems and data, definition of success criteria that can be checked objectively.
- ARCHITECTURE
A documented target design with explicit boundaries, interfaces, data ownership and a migration path from the current state.
- DELIVERY
Iterative implementation with automated tests, code review, environment parity and demonstrations against real scenarios.
- HANDOVER
Runbooks, architecture notes and knowledge transfer sessions so the client's team can operate independently.
04Quality philosophy
Quality is a property of the process
We treat quality as something built into how work is done rather than something checked at the end. Requirements are written so they can be tested. Changes are reviewed by a second engineer. Automated tests run on every commit, and a change that breaks them does not progress.
Manual testing is reserved for exploratory work and scenarios that genuinely require human judgement. Defects found after release are traced back to the stage that allowed them through, and the process is adjusted rather than the individual blamed.
05Collaboration model
One team, one backlog
Our engineers work inside the client's planning rhythm. A single prioritised backlog is maintained jointly, with a named decision-maker on the client side for scope questions. Progress is visible continuously rather than summarised at milestones.
Depending on the engagement we act as the full delivery team, as a specialist unit inside a larger programme, or as an advisory group supporting an internal team. The communication cadence, environments and access model are agreed at the start and written down.
06Values
Clarity
Plain language in specifications, status reports and technical documentation.
Rigour
Reviewed code, tested changes, reproducible environments, controlled releases.
Longevity
Solutions that a client's own team can operate, extend and eventually replace.
Restraint
No technology introduced without a concrete reason tied to a requirement.
