Mission
To build software that organisations can rely on and continue to change safely. That means systems whose behaviour is understood, whose infrastructure is reproducible, and whose code can be picked up by another engineer without archaeology.
About us
An engineering
company, first.
House 55 GmbH is an IT company that designs, builds and maintains software systems. We describe here how we work, what we hold ourselves to, and what we will not claim.
01Introduction
Software work carried out by the people who explain it.
House 55 GmbH provides IT services across custom software, web and mobile applications, cloud infrastructure, design, quality assurance, security consulting and data engineering. Engagements vary in size, but the working method does not: understand, design, build in short cycles, verify, release, operate.
We publish only what we can substantiate. You will not find invented client lists, statistics, certifications or awards on this website. What we can offer instead is a clear description of our method and a direct line of communication by email.
02Mission and vision
Vision
A technology practice where careful engineering is the normal standard rather than a premium: where security, accessibility, testing and documentation are part of ordinary delivery, and where clients can read and question every significant decision made on their behalf.
03Values
What we hold ourselves to.
Clarity
A system that cannot be explained simply is usually not understood well enough to be trusted.
Craft
Readable code, considered interfaces and documentation written while the reasoning is still fresh.
Honesty
Estimates, risks and mistakes are reported as they are, including when the news is inconvenient.
Durability
We build for the team that inherits the system, not only for the release in front of us.
Restraint
Fewer moving parts, fewer dependencies, fewer clever shortcuts that only one person understands.
Responsibility
Ownership does not end at deployment; it continues while the software is in use.
04Working principles
Seven rules that shape day-to-day delivery.
- 01
Understand the problem in the client's own language before proposing a solution.
- 02
Write down architectural decisions and the reasoning behind them.
- 03
Deliver working software in short cycles rather than long, unverifiable phases.
- 04
Prefer proven technology; justify anything unusual in writing.
- 05
Automate anything that must be repeated reliably.
- 06
Treat security and accessibility as requirements, not as later improvements.
- 07
Leave every system in a state another team could take over.
05Team and collaboration
Small teams, direct communication, shared tooling.
Work is organised into small teams that stay with a project rather than rotating through it. Clients are given access to the same repositories, issue trackers and environments the team uses, so progress can be inspected at any point instead of being reported second-hand.
Where an in-house team already exists, we integrate into their rituals — the same standups, review process and definition of done — rather than running a parallel process alongside them.
06Engineering culture
Culture shows up in the pull request, not the poster.
Review over approval
Reviews look for risk, clarity and missing tests. Style disagreements are settled by automated formatting.
Written reasoning
Architecture decisions are recorded so a future engineer can understand why, not just what.
Blameless incidents
When something breaks, we examine the system that allowed it rather than the person who triggered it.
Continuous learning
Time is set aside to read, prototype and evaluate technology properly before it reaches a client system.
07Quality and security commitments
Automated verification
Unit, integration and end-to-end tests run in continuous integration on every change.
Secure defaults
Authentication, authorisation, transport security and input validation are designed in from the start.
Dependency hygiene
Third-party packages are kept current and monitored for published vulnerabilities.
Data minimisation
Systems collect and retain the data they need for the purpose at hand, and no more.
Accessible interfaces
Semantic markup, keyboard operability and contrast are treated as functional requirements.
Clean handover
Documentation, infrastructure code and credentials are transferred so you are never dependent on us to operate.
08Company contact information