We draw software the way engineers draw buildings.
Feel Holiday GmbH is a software engineering studio. We plan digital systems on paper before writing them in code, and we treat every service, database and interface as part of a deliberate, documented whole.
- Discipline
- Software
- Practice
- Engineering
- Scope
- Web · Mobile · Cloud
- Horizon
- Long-term
A studio that treats software as long-lived infrastructure, not as disposable output.
Feel Holiday GmbH is a European engineering practice that partners with organisations building, running or modernising digital systems. Our work spans product engineering, platform engineering and the operational discipline required to keep both healthy over time.
We are opinionated about the fundamentals — clarity, small interfaces, honest estimates, tested code, observable systems — and pragmatic about everything else. Our clients tend to stay with us for years because the software we deliver continues to make sense a year, two years, five years later.
- Legal name
- Feel Holiday GmbH
- Contact
- samuelmart32@gmail.com
- Domain
- feelvacation.com
- Working language
- English
Six practices at the centre of what we do.
The disciplines below are not marketing categories — they are the work our engineers do on any given week.
- Practice · A
Product engineering
Turning a business idea into a working, maintainable product without accumulating hidden debt in the process.
- Practice · B
Platform & infrastructure
The cloud environments, deployment pipelines and observability that let a product run predictably at scale.
- Practice · C
Systems integration
Connecting disparate services, APIs and internal tools so that data moves reliably instead of by copy-paste.
- Practice · D
Data architecture
Modelling and storing information so that today's features and tomorrow's questions both remain answerable.
- Practice · E
Interface engineering
Implementing user interfaces that are accessible, responsive, and behave the same way at 3 a.m. as at 3 p.m.
- Practice · F
Quality & operations
Testing strategies, monitoring, incident response and the long tail of production maintenance.
The situations that usually bring an organisation to us.
A software product that started small and is now hard to change.
Feature work slows down, incidents multiply and the team spends more time firefighting than building. We help isolate the parts that need to be rewritten from the parts that only need to be reinforced.
A manual process that has quietly become critical.
Spreadsheets, exported CSVs and internal scripts that once helped are now the backbone of daily operations. We convert them into proper internal tools with clear ownership and audit trails.
An idea that must be validated with a real product, not a slide deck.
We build focused first versions with the smallest surface area that can teach the business something honest, and design them so that a successful version can grow.
Data spread across systems that do not talk to each other.
Customer, product and financial data living in separate places, each with its own truth. We design and implement the integrations, reconciliation and reporting layer.
A legacy system that still runs the business.
A codebase written a decade ago, poorly documented, expensive to change, but too central to switch off. We stabilise, document, and modernise it in defensible steps.
Software that must keep working long after the project ends.
Ongoing maintenance, monitoring, security patches and iterative improvements under a clear operational agreement.
A concise map of everything we build and operate.
The list below is the same one we use internally when we describe our capacity. It is deliberately narrow: we would rather be excellent at a well-defined set of things than mediocre at everything.
- S · 01Custom software development
End-to-end engineering of applications built specifically for a business process, not adapted from a template.
- S · 02Web applications
Server-rendered and single-page applications, admin consoles, portals, marketplaces and internal tooling.
- S · 03Mobile applications
Native and cross-platform mobile clients designed to share logic with web counterparts where sensible.
- S · 04Cloud solutions
Design and operation of cloud environments across storage, compute, networking and identity.
- S · 05APIs & system integration
Public and internal APIs, event pipelines and integrations with third-party services.
- S · 06UI & UX implementation
Careful translation of design systems into accessible, responsive, tested interface code.
- S · 07Software architecture consulting
Independent architectural reviews, technology decisions and roadmap work with in-house teams.
- S · 08Legacy system modernisation
Stabilisation, decomposition and progressive replacement of long-standing production systems.
- S · 09Quality assurance & testing
Automated testing strategy, regression coverage and manual verification of critical paths.
- S · 10DevOps & infrastructure
Continuous integration and delivery pipelines, environment management and infrastructure as code.
- S · 11Data-driven digital solutions
Data models, warehouses, analytics pipelines and internal reporting.
- S · 12Ongoing software maintenance
Continued support of software already in production under defined service terms.
A more detailed description of each service, including typical deliverables and technical considerations, is available on the Services page.
The tools we reach for, and how we choose them.
We are technology-agnostic in principle and opinionated in practice. The right technology is the one whose trade-offs the team can explain out loud.
TypeScript and JavaScript for interface and application code. Python and Go for services, data work and internal tooling. SQL as a first-class citizen.
Modern component-based frameworks with strict typing, deliberate state management and accessible, responsive rendering across devices.
HTTP and event-based services with well-defined contracts, tested boundaries and honest error handling.
Relational databases as the default, complemented by object storage, search indexes and analytical stores where the workload requires it.
Managed cloud environments with infrastructure defined as code, reproducible deployments and cost visibility from day one.
Structured logs, metrics and traces designed together with the code they instrument, so incidents can be understood without guesswork.
Small teams, short cycles, written decisions.
Small integrated teams
Every project runs with a small, cross-functional team. Fewer handoffs, more shared context, faster and more accurate decisions.
Short iterative cycles
Work is planned in short cycles with visible outputs. Direction can be adjusted every week rather than every quarter.
Written decisions
Non-trivial choices are documented as short design notes. Future engineers — including our own — should be able to understand not just what was built, but why.
Progressive delivery
We ship small, reversible changes behind flags and staged environments. Big-bang releases are the exception, not the rule.
Testing as design
Tests are part of how a feature is designed, not something added afterwards. This is what makes safe change possible.
Honest estimation
We prefer to give small, honest ranges early and refine them as we learn, rather than committing to precise numbers we do not yet believe.
How a project moves from a first conversation to a system in production.
- 01Discovery
We understand the problem, the users involved and the constraints — technical, regulatory and organisational.
- 02Definition
The scope, deliverables and success criteria of the first phase are agreed in writing.
- 03Design
Architecture, data model and key interfaces are drafted before large amounts of code are written.
- 04Build
Implementation proceeds in short, visible cycles with continuous testing and internal review.
- 05Release
Software is deployed to production progressively, under monitoring, with a clear rollback plan.
- 06Operate
Once live, the system enters an operational phase with defined support, monitoring and iteration.
The kinds of business contexts we are comfortable operating in.
Our work is not restricted to a single industry, but there are contexts we know especially well. The common thread is that software is not a side project — it is part of how the business runs.
- Digital products
Consumer and B2B products where the software is itself the offering.
- Operations & internal tools
Custom internal tooling that supports logistics, back office, support and administration.
- Regulated environments
Contexts with strong requirements around data protection, auditability and change management.
- Data-heavy businesses
Organisations whose competitive edge depends on the quality and accessibility of their data.
- Platforms & marketplaces
Multi-sided systems where different user types interact through shared infrastructure.
- Established companies modernising
Organisations with existing systems that need to evolve without losing operational stability.
Security is a property of a system, not a feature bolted onto it.
- Least privilege by default
Access to data and systems is granted narrowly and reviewed regularly rather than granted broadly and forgotten.
- Defence in depth
No single mechanism is expected to be perfect. Authentication, authorisation, network boundaries and validation reinforce each other.
- Secure defaults
Frameworks, libraries and configurations are chosen so that the safe path is the easiest path for engineers to take.
- Auditable change
Every change to production is traceable to a specific commit, review and deployment.
- Incident readiness
Runbooks, monitoring and clearly designated responsibilities so that the response to an incident is rehearsed, not improvised.
Confidence in software comes from the process, not from the last-minute review.
Quality assurance at Feel Holiday GmbH is a continuous activity that runs alongside implementation, not a phase inserted before release.
- Automated test suites
- Unit, integration and end-to-end tests written together with the features they cover.
- Continuous integration
- Every proposed change is built and tested automatically before it can be merged.
- Code review
- Non-trivial changes are reviewed by at least one other engineer before landing on the main branch.
- Static analysis
- Linters, type checkers and security scanners are part of the standard build pipeline.
- Manual verification
- Critical paths are exercised manually before release, with structured checklists.
- Post-release monitoring
- Newly released changes are watched actively so that regressions are seen early, not by users.
What tends to matter to the organisations that work with us.
Work is done by engineers who have taken systems from an empty repository to running in production, more than once.
Decisions, trade-offs and status are written down. Nothing important lives only in a single person's head.
We prefer to do a bounded set of things extremely well rather than offer every possible service.
We optimise for what the code and the system will look like in a year, not just for what ships this sprint.
Fewer layers between the people writing the software and the people who need it.
Comfort not only with building software but with running it: incidents, backups, upgrades, deprecations.
Every organisation is different. We adapt to how you already work rather than imposing a rigid methodology.
No self-promotion, no invented case studies. What we say about our work matches what our work actually is.
Every project begins on paper.
Before code is written, we draw. Boxes and arrows for the system. Wireframes for the interface. Sequence diagrams for the interactions that matter. This unfashionable habit consistently prevents the most expensive kinds of mistake: the ones that only become visible once the software is already in production.
A few of the questions we hear most often.
Q · 01What kind of projects does Feel Holiday GmbH work on?↳
We work on custom web and mobile applications, cloud infrastructure, API and system integration, quality assurance, modernisation of legacy systems and long-term maintenance of production software.
Q · 02How does a typical engagement start?↳
An engagement begins with a short written exchange to understand the problem, its context, the constraints involved and the outcome that would qualify the work as successful. From there we agree on a small, well-defined first phase.
Q · 03Do you work with existing codebases or only greenfield projects?↳
Both. A significant part of our work involves inheriting, stabilising and gradually modernising software that is already running in production.
Q · 04How is progress communicated during a project?↳
We work in short, visible cycles with written summaries, running documentation, demo builds and a shared backlog. Stakeholders should never need to ask where a project stands.
Q · 05What happens after a project goes live?↳
Systems evolve after launch. We offer continued maintenance, monitoring, incident response, security updates and iterative feature work under clear service terms.
A small studio building software that outlives the project.
Feel Holiday GmbH is a European software engineering studio that plans, builds and maintains digital systems for organisations that treat software as core infrastructure. We prefer small teams, written decisions and long-term relationships.
If you would like to discuss a project, an existing system or a decision you are trying to make, written correspondence is the fastest way to reach us.
Interface work at Feel Holiday GmbH is treated with the same discipline as backend architecture: measured, annotated and reasoned about before it is coded.
