How we workSix principles for our projects that we hold ourselves to
Clarity before complexityKlarheit vor Komplexität
Before anyone starts — whether that's design, coding, or automation — the task needs to be understood. Sounds obvious, yet it gets skipped constantly. Picking a new software tool is faster than describing a problem.
It's fine for things to stay complicated after that. Not for them to stay unclear.
What that means in practice: We write down what we've understood. What we're only assuming is labeled as an assumption.
Accessible by defaultZugänglichkeit als Basis
Our solutions, automations, and software need to be accessible to you. That especially includes enabling your team, but also accessibility in the sense of readability.
What that means in practice: We build solutions for people.
Built beyond launchNachhaltig entwickelt
After handover, someone else needs to be able to keep working with it. Launch is the start of live operation, not the end of the project.
We always build solutions so that you don't need us. Unless, of course, you want to.
What that means in practice: Documentation, access, and onboarding are part of the delivery. You can carry on without us at any time.
Technology with a reasonTechnologie mit Sinn und Verstand
We choose technology, software, and the use of AI based on whether it fits the task, not on how widespread it currently is.
Sometimes the answer is that you don't need anything new at all.
What that means in practice: For every technology decision, we tell you exactly why we decided the way we did.
Honest trade-offsEhrliche Kompromisse
Every serious solution has downsides. Anyone who doesn't see them either hasn't thought it through or is keeping quiet about them.
We say clearly what we prioritized, what falls away, and what risk we're accepting by doing so.
What that means in practice: Every proposal states what's not included. Every recommendation states what speaks against it.
Maintainable by peopleEinsetzbar durch Menschen
Beautiful code isn't enough. What matters is whether your team can handle it day to day and actually works with it.
Software that only its developers understand is wasted effort.
What that means in practice: We write code and content so that someone new understands them without us, and so the software is simply usable.