Clarity
If a decision cannot be explained in plain English, it is not yet understood.
Drawing 002 · Company profile
About Smile Aid GmbH
Smile Aid GmbH is an IT company. We design, build, integrate and maintain software systems for organisations that depend on those systems to operate. This page describes how we work and what we hold ourselves to.
01Company introduction
Who we are
We are an engineering-led company. Our work begins with understanding a problem precisely enough to describe it in writing, and continues until the resulting system runs, is observable, and can be maintained by the people who own it.
We work across the full lifecycle rather than a single phase: analysis and architecture, implementation, integration with existing systems, deployment automation, and the ongoing revision that every living system requires.
All of our documentation, communication and reporting is produced in English.
02Mission and values
What we are trying to do
Our mission is to build software that remains understandable and changeable for as long as an organisation needs it. A system that works today but cannot be safely modified tomorrow has only postponed its cost.
Honesty
Unknowns, risks and errors are reported as soon as they are recognised.
Durability
We optimise for the second year of a system's life, not only the first release.
Restraint
We add technology when it is justified, and remove it when it is not.
03Work principles
Principles that shape day-to-day delivery
- 01
Understand before changing
We read the existing system, its data and its deployment path before proposing modifications.
- 02
Write the decision down
Architecture notes, interface definitions and trade-offs are recorded where the team can find them.
- 03
Deliver in reviewable slices
Work is cut into increments that can be inspected, tested and reversed.
- 04
Automate what repeats
Builds, tests, environment provisioning and deployments are scripted rather than remembered.
- 05
Leave the codebase clearer
Every change should make the next change slightly easier.
- 06
Hand over completely
Credentials, documentation and operational knowledge transfer to the owner at the end.
04Technical mindset
How we think about systems
We treat software as an engineered artefact with measurable properties: latency, failure modes, resource consumption, and the effort required to change it. When those properties matter, we measure them instead of estimating them.
We prefer simple structures that can be reasoned about over clever ones that cannot. Abstractions are introduced when repetition justifies them, not in anticipation of requirements that may never arrive.
When a system fails, we look for the condition that made the failure possible rather than the individual line that expressed it, and we address that condition.
05Quality standards
The standards we apply to our own work
Review
Changes are read by another engineer before they are merged, with attention to correctness, clarity and security implications.
Testing
Automated tests are written at the levels where they provide real signal: unit tests for logic, integration tests at boundaries, and checks around critical paths.
Continuous integration
Every change runs through the same build, test and static analysis pipeline, so failures surface early.
Environment parity
Development, staging and production are described by the same configuration so behaviour is comparable.
Observability
Structured logs, metrics and traces are added with the feature, so problems can be diagnosed without guesswork.
Documentation
Interfaces, operational procedures and known limitations are written down and kept current.
06Long-term cooperation
Approach to long-term cooperation
Most software relationships are long, so we design them to survive changes of personnel on both sides. That means shared documentation rather than private knowledge, predictable release rhythms, and a backlog whose priorities are agreed rather than assumed.
We are comfortable working alongside an internal team, contributing to a shared repository under its conventions, or taking responsibility for a defined component end to end. The arrangement is written down at the start and revisited when the work changes shape.
If a cooperation ends, it should end cleanly: access revoked, documentation current, and no undocumented dependency on us remaining in the system.
- Cadence
- Agreed in advance and kept predictable
- Reporting
- Written progress notes in English
- Ownership
- Code and documentation belong to the client
- Exit
- Clean handover with revoked access
07Responsible technology practices
Responsibility in how systems are built and run
Data minimisation
We collect and retain only the data a system genuinely needs, and we make retention explicit rather than accidental.
Privacy by design
Personal data handling is considered when the data model is drawn, not after the feature ships.
Accessibility
Interfaces are built with semantic markup, keyboard operability and sufficient colour contrast.
Resource awareness
We size infrastructure to actual load and remove unused resources, which reduces both cost and energy use.
Dependency hygiene
Third-party components are inventoried, licence-checked and updated deliberately.
Transparent limitations
Where a system cannot guarantee something, we say so in writing instead of implying otherwise.