About us
A technology practice built around maintainability
MyraClean Gebäudereinigung GmbH provides IT services and technology consulting. The work is software engineering in the ordinary sense: understanding a problem properly, building something appropriate to it, and leaving behind a system that other people can operate and change.
Introduction
What the practice does
The practice serves organisations whose operations depend on software that has grown organically: internal tools written for one purpose and stretched into another, reporting assembled by hand each month, or platforms whose original authors have moved on.
Engagements range from a short assessment — reading a codebase and its infrastructure and writing down what is actually there — to designing and building a new application, to keeping a delivered system healthy over time. What stays constant is the emphasis on written scope, incremental delivery and honest description of trade-offs.
This page describes method and intent. It deliberately makes no claims about company history, size, certifications, partnerships or past clients, because such claims should only be made where they can be substantiated.
Working principles
Six commitments that shape the work
Understand before building
Discovery is not a formality. The people who perform a process daily know where it bends, and that knowledge belongs in the design.
Prefer the smaller change
Where a configuration change, a fix or a modest addition would solve the problem, that is the recommendation, even when a larger project would be more lucrative.
Write things down
Decisions, assumptions, risks and open questions live in a shared written record, so nothing depends on recalling a conversation.
Deliver in reviewable increments
Working software at the end of each iteration, in an environment the client can open and use.
Build for handover from day one
Documentation, environment definitions and runbooks are produced alongside the code, not retrofitted at the end.
Describe limits plainly
Where an outcome cannot be promised — performance under unknown load, security, regulatory compliance — that is stated rather than implied.
Engineering philosophy
Boring technology, carefully applied, tends to last
Novel tools are chosen only when they solve a problem the mainstream options cannot. Otherwise the preference is for well-documented languages, relational databases, managed services with clear operational models, and architectures that a competent engineer can understand within a day of reading.
- Simplicity is a feature. Fewer moving parts means fewer failure modes and a shorter path from symptom to cause.
- The data model outlives the UI. Time spent on entities, relationships and constraints pays back for years.
- Automate the repeatable. Builds, tests, migrations and deployments run the same way every time, from a pipeline rather than from a laptop.
- Reversibility over cleverness. A change that can be rolled back is worth more than an elegant one that cannot.
Collaboration approach
How we work alongside an internal team
Shared visibility
The backlog, the environment and the written decision log are open to the client throughout. There is no separate internal version of project status.
Defined contacts
One person on each side owns technical questions, so answers do not stall in group threads.
Working sessions, not presentations
Reviews happen in the running system, with the people who will use it, in short focused sessions.
Knowledge transfer as a habit
Pairing, written walkthroughs and commented pull requests mean the client team learns the system while it is being built.
Respect for existing constraints
Procurement rules, security policies and legacy dependencies are treated as design inputs rather than obstacles to argue about.
Clear endings
Every engagement has a defined completion state: what is delivered, what is documented, and what support arrangement follows.
Maintainable technology
A system is finished when someone else can run it
Maintainability is measured practically: can a new engineer set up the project locally from the written instructions? Can a release be rolled back? Is it clear which service owns which data? Does an alert lead to a documented response? If the answers are yes, the software can survive staff changes and years of small modifications.
Concretely, that means dependency versions pinned and updated on a schedule, infrastructure described in code, migrations that run automatically and in order, configuration separated from code, and documentation kept in the same repository as the system it describes.
Written enquiries: [email protected] — myraclean.com. All contact details on this website are shown as plain text.