§ 01 — About
A studio built around careful engineering.
Yoto GmbH is a software engineering studio. We design, build and modernise custom applications, cloud platforms and integrations for organisations that intend to operate their software for many years.
Fig. A/01 — Notation
§ 02 — Approach
Small teams, written decisions, working software.
We work in small teams that stay together through the life of a project. Each engagement starts with a written scope, an architecture proposal and an agreed cadence for review. We prefer fewer concurrent projects over more, and we say no to work we cannot do well.
We do not have a fixed technology stack that we push onto every client. Instead we choose the tools that fit the problem, the organisation running the result and the engineers who will maintain it.
§ 03 — Mission
To build software that continues to make sense five years after it is delivered.
The mission is deliberately narrow. It rules out work that trades long-term quality for short-term appearance, and it rules in work that requires patience, documentation and care.
§ 04 — Values
Five that we can defend.
- V/01
Honesty over polish
Status reports describe what is actually working, not what we would like to present.
- V/02
Simplicity where possible
The simplest design that solves the problem is preferred over the most impressive one.
- V/03
Ownership of decisions
Every architectural choice has an owner who can be asked to explain it.
- V/04
Long-lived code
We write for the team that will maintain the system after us.
- V/05
Respect for existing work
Legacy systems represent decisions made under real constraints. We read them carefully before proposing changes.
§ 05 — Working principles
Practical rules we hold ourselves to.
- P/01
Write down what will be built before writing the code.
- P/02
Prefer boring, well-understood technology unless there is a reason not to.
- P/03
Automate the parts of the work that are done more than twice.
- P/04
Log enough to understand a production incident without a debugger.
- P/05
Assume the next engineer on this file has no context and be kind to them.
- P/06
Say no to work that cannot be done well within the agreed constraints.
§ 06 — Quality philosophy
Quality is a working habit.
Testing, review and observability are part of the work as it is produced, not a phase added on later. We aim for code that is boring to read, straightforward to deploy, and possible to reason about when things go wrong at 3 a.m.
We do not claim to eliminate defects; we claim to reduce them systematically, to detect them early and to respond to them honestly.
§ 07 — Communication
Plain English, in writing.
We communicate in English. We prefer writing over meetings because writing forces us to be precise and leaves a record that can be reviewed later. Meetings happen when a decision genuinely needs a conversation.
For every engagement there is a shared document that lists what is being built, what is currently blocking progress and what has been decided. Clients can read it at any time.
§ 08 — Collaboration model
How a project moves.
- C/01
A written brief
The starting point is a short document describing the situation, the goal and the constraints.
- C/02
A technical assessment
We review the brief with an engineer, ask questions and reply with an honest assessment of what is realistic.
- C/03
A scoped engagement
If the fit is right we agree on scope, team, cadence and commercial terms in a single written agreement.
- C/04
Delivery in short cycles
Work moves in short cycles with visible progress. Direction can be adjusted at the end of any cycle.
