Explicit over clever
Code that states its intent plainly is cheaper to maintain than code that demonstrates ingenuity.
AAbout us
About KiS GmbH
KiS GmbH is an IT company focused on building and maintaining the software and infrastructure that organisations use to run their work. We describe what we do and how we do it — nothing here is embellished with history, headcount or figures we cannot support.
Purpose and approach
Our purpose is straightforward: make business technology dependable. Most of the cost in software appears after the first release, in the years of changes, integrations and operational work that follow. We aim to reduce that cost by building systems that are simple to understand and safe to modify.
In practice, that shapes how we start. Before proposing a solution we spend time on the problem — the process, the data, the people who depend on it and the systems already in place. A well-framed problem usually produces a smaller, clearer piece of software than the one originally imagined.
We prefer incremental delivery over long silent phases, established technology over novelty for its own sake, and written decisions over informal agreement.
Working values
How we prefer to work
Clarity before speed
Work that starts with an agreed understanding finishes faster than work that starts with assumptions.
Proportionate solutions
The right amount of technology for the problem, with room to grow rather than complexity bought in advance.
Transparency about uncertainty
Where something is unknown we say so, and we describe how we intend to reduce the unknown.
Respect for existing systems
Systems that are still in use exist for reasons. We understand them before recommending replacement.
BEngineering philosophy
Software is read far more often than it is written
Boundaries that hold
Clear separation between domains, data access and interfaces keeps change local instead of systemic.
Tests where risk lives
Automated coverage concentrated on logic that would be expensive to get wrong, rather than coverage as a target.
Automation of the routine
Builds, deployments and checks run the same way every time so human attention stays on the difficult parts.
Operable by design
Logging, metrics and configuration are part of the feature, not an addition after the first incident.
Reversible steps
Changes are shaped so they can be rolled back or superseded without a rescue project.
CCollaboration principles
Working with your people
The people who know a business best are already inside it. Our role is to translate that knowledge into systems, and to leave the organisation more capable of looking after those systems than it was before.
- Regular, predictable communication rather than reporting on request
- Direct contact between the people building the system and the people using it
- Documentation and knowledge transfer treated as part of delivery
- Openness to internal teams reviewing, extending or taking over the work
- Clear scope boundaries, with changes discussed rather than absorbed silently
DQuality and maintainability
Built for the years after launch
Quality shows up in how a system behaves when it is under pressure and how it feels to change eighteen months later. We treat both as measurable parts of the work.
Review as routine
Every change is read by someone other than its author before it reaches a shared environment.
Dependencies kept current
Regular updates, so upgrades remain small tasks instead of migration projects.
Environment parity
Test and production environments described the same way to reduce surprises at release.
Documentation that survives
Setup, architecture and operational notes kept close to the code they describe.