A studio of software engineers,
writing systems that last.
This page is a plain description of who Feel Holiday GmbH is, what we care about and how we approach the work. Nothing on this page is a promotional claim.
What Feel Holiday GmbH is, in plain terms.
Feel Holiday GmbH is a European software engineering practice. We design, build and maintain digital systems on behalf of organisations that need software to run reliably as part of their operations. Our work is delivered by engineers, in small teams, working directly with the people whose problem is being solved.
Our mission
To help organisations turn complex problems into software that is clear, safe to change and honest about its own limits. We measure success by whether the systems we build continue to serve the business years after the initial engagement has ended.
Our vision
A software industry where engineering discipline is the default expectation, not a premium option. Where the people responsible for a system understand it, and where the systems themselves are documented well enough that the next engineer can inherit them without alarm.
Six principles that guide how we work.
We favour code, interfaces and explanations that the next person to read them can understand quickly.
We give the ranges we actually believe, revise them as we learn, and flag risks early.
Non-trivial decisions are written down. This is how a team stays coherent over time.
We build software as though we were going to be responsible for it in three years, because we often are.
The right amount of process is the least amount that keeps quality and predictability high.
We adapt to the client's constraints, culture and existing systems instead of imposing a template.
How work actually happens, day to day.
- Small teams by default
One or two engineers, sometimes three. Enough to have a real conversation, small enough to move without friction.
- Direct client contact
The people writing the software talk to the people who need it. Requirements are not transcribed through intermediaries.
- Short, visible cycles
Weekly increments with running builds and written summaries.
- Everything in a repository
Code, infrastructure definitions, documentation and decisions all live under version control.
- Reversible releases
Deployments are small, staged and easy to roll back.
- Reviewed changes
Non-trivial changes are read by a second pair of eyes before landing.
How we think about software as a discipline.
We consider software engineering a serious craft with tangible economic consequences. Every line of code either supports the business or slowly costs it money. The engineering mindset we cultivate is built around that reality.
The most expensive mistakes happen when the problem was never really understood in the first place.
Well-defined interfaces between components are what allow a system to be understood and changed over time.
Interfaces come and go, but data outlives them. We invest in modelling it carefully from the beginning.
Engineers who deploy and observe their own code write different, better code.
Well-understood tools beat exciting ones for anything that must stay running.
The next feature, the next migration, the next engineer — all deserve to inherit code that is easy to move.
What working with us actually looks like.
We treat collaboration as part of the engineering work, not as an overhead. That means fewer meetings and more written artefacts, but the artefacts that do exist — proposals, notes, changelogs — are careful and honest.
- · Weekly written status.
- · Shared backlog with visible priorities.
- · Design notes before major changes.
- · Access to running builds throughout.
- · Clear ownership on each work item.
- · Direct engineer-to-stakeholder contact.
What we consider a minimum, not a bonus.
- Standard · 01Version-controlled everything
Every artefact that affects production — code, configuration, infrastructure — lives under version control.
- Standard · 02Automated build and test
Every change is built and tested before it can be merged; no green light, no merge.
- Standard · 03Reviewed changes
Substantive changes require a second engineer's approval.
- Standard · 04Observable systems
Logs, metrics and traces are treated as part of the product, not as an afterthought.
- Standard · 05Documented decisions
Non-trivial choices are recorded so that future engineers can understand the reasoning.
- Standard · 06Reproducible environments
Development, staging and production environments are defined as code.
We work with clients on a horizon of years, not weeks.
Software that has to run for years is a different object than software that only has to demo well. We optimise for the former. Our engagements are structured around the assumption that we will still be able to look at the system three years from now and be proud of it.