Feel Holiday GmbHFeel/Holiday
Menu
Document 02 · Services catalogue

What Feel Holiday GmbH
designs, builds and maintains.

A concise catalogue of our services. Each entry describes what the work is, the situations in which it is usually requested, the deliverables that typically come with it, the technical considerations that shape it and the business value it is intended to produce.

Blueprint schematic of cloud infrastructure with servers and network topology drawn in white lines on navy background
Preface

We work best when a service is chosen because it fits a real business problem, not because it fits a category on a website. The descriptions on this page are meant to help recognise which shape of engagement matches which shape of problem.

Most of our real engagements combine several of these services. Building a new product almost always involves some architecture consulting, some cloud work and, eventually, some maintenance.

§ 00
Index

Services in this document.

  1. S01Custom software development
  2. S02Web application development
  3. S03Mobile application development
  4. S04Cloud solutions
  5. S05API development and system integration
  6. S06UI and UX implementation
  7. S07Software architecture consulting
  8. S08Legacy system modernisation
  9. S09Quality assurance and testing
  10. S10DevOps and infrastructure support
  11. S11Data-driven digital solutions
  12. S12Ongoing software maintenance
S01
01

Custom software development

End-to-end engineering of applications shaped specifically around a business process, rather than adapted from an off-the-shelf template.

Typical business needs
  • —A workflow that does not fit standard tools.
  • —Requirements that change often as the business learns.
  • —A need for tight integration with existing internal systems.
Main deliverables
  • —A working application deployed to a controlled environment.
  • —Source code held in a repository owned by the client.
  • —Written documentation describing the architecture and key decisions.
Technical considerations
  • —Domain modelling done carefully at the start.
  • —Boundaries between modules that will not collapse under future change.
  • —Testing strategy proportionate to the risk of each area.
Expected business value
  • —Software that reflects how the business actually operates, and that can evolve as that operation evolves.
S02
02

Web application development

Server-rendered and single-page web applications: portals, admin consoles, dashboards, marketplaces and internal tools.

Typical business needs
  • —A user-facing interface that must run reliably across browsers and devices.
  • —Non-trivial application logic behind that interface.
  • —Requirements for accessibility, responsiveness and performance.
Main deliverables
  • —Frontend and backend code, integrated and deployed.
  • —Authentication, authorisation and audit logging where relevant.
  • —Automated tests covering key user journeys.
Technical considerations
  • —Rendering strategy chosen for the actual audience and workload.
  • —State management that will not become a source of subtle bugs.
  • —Performance budget defined and monitored from day one.
Expected business value
  • —A web application that is enjoyable to use, safe to change and easy for a small team to operate.
S03
03

Mobile application development

Native and cross-platform mobile applications engineered for consistent behaviour across devices and network conditions.

Typical business needs
  • —A user experience that must feel native to the mobile platform.
  • —Offline behaviour, background work or platform integrations.
  • —Shared logic with an existing web product.
Main deliverables
  • —Application builds for the target platforms.
  • —Backend or API adjustments required for mobile consumption.
  • —Release pipeline for app-store or enterprise distribution.
Technical considerations
  • —Battery, network and permission behaviour on real devices.
  • —Update cadence, given app-store review cycles.
  • —Testing on a representative range of devices, not only the newest.
Expected business value
  • —A mobile product that users can rely on across the full range of conditions in which they actually use it.
S04
04

Cloud solutions

Design, implementation and operation of cloud environments — networking, compute, storage, identity and observability.

Typical business needs
  • —An application that needs to run somewhere predictable and scalable.
  • —Compliance or reliability requirements that rule out ad hoc hosting.
  • —A team that lacks in-house cloud expertise but must move quickly.
Main deliverables
  • —Cloud environments defined as code.
  • —CI/CD pipelines with reproducible deployments.
  • —Monitoring, alerting and cost visibility.
Technical considerations
  • —Cost profile understood before scale, not after.
  • —Security posture aligned with the sensitivity of the data.
  • —A clear boundary between shared and application-specific infrastructure.
Expected business value
  • —Infrastructure that is predictable to run, reasonable to pay for and safe to change.
S05
05

API development and system integration

Public and internal APIs, event pipelines and integrations with third-party services, designed so that data moves reliably between systems.

Typical business needs
  • —Data trapped in one system that other systems need.
  • —Third-party services that must be integrated coherently.
  • —External developers or partners who must consume an interface.
Main deliverables
  • —Documented API contracts, versioned and tested.
  • —Integration components with clear error handling.
  • —Monitoring for interface health and correctness.
Technical considerations
  • —Compatibility strategy for evolving contracts over time.
  • —Idempotency and retry behaviour for critical flows.
  • —Realistic authentication and rate-limiting for the intended consumers.
Expected business value
  • —A predictable, well-documented interface layer between systems that would otherwise diverge.
S06
06

UI and UX implementation

Careful translation of design systems and interface designs into accessible, responsive, tested code.

Typical business needs
  • —Design work that has to be implemented faithfully across breakpoints.
  • —A component library that needs to be extended or consolidated.
  • —Accessibility requirements that must be met, not just approximated.
Main deliverables
  • —Reusable interface components with documented behaviour.
  • —Interfaces that meet contemporary accessibility standards.
  • —Visual and interaction tests where they add value.
Technical considerations
  • —Behaviour under real content, not just placeholder content.
  • —Keyboard, screen-reader and reduced-motion experience treated as first-class.
  • —Performance on lower-end devices, not only on developer machines.
Expected business value
  • —Interfaces that behave the way they were designed to behave, including in the situations the design did not anticipate.
S07
07

Software architecture consulting

Independent architectural reviews, technology decisions and roadmap work carried out alongside an in-house team.

Typical business needs
  • —A significant technical decision that has to be made well.
  • —A team that would benefit from a second, experienced perspective.
  • —A system whose future direction is uncertain.
Main deliverables
  • —Written architectural assessment with concrete recommendations.
  • —Prototype or spike work where a decision cannot be made on paper.
  • —A prioritised roadmap for evolving the system.
Technical considerations
  • —Recommendations calibrated to the team's actual capacity.
  • —Trade-offs made explicit, not hidden inside a preference.
  • —Migration paths that can be executed incrementally.
Expected business value
  • —Decisions that hold up when re-read in twelve months, and that the in-house team can defend on their own.
S08
08

Legacy system modernisation

Stabilisation, decomposition and progressive replacement of long-standing production systems that still power the business.

Typical business needs
  • —A system that is critical but expensive to change.
  • —Original authors who are no longer available.
  • —A business need that the current system cannot meet without a rewrite.
Main deliverables
  • —An assessment of the current system's structure and risks.
  • —A concrete, staged modernisation plan.
  • —Refactored or replaced components, delivered incrementally.
Technical considerations
  • —Preserving the behaviour the business actually depends on.
  • —Avoiding a big-bang rewrite in favour of reversible steps.
  • —Keeping the system live and serving traffic throughout.
Expected business value
  • —A system that becomes safer to change without an interruption to the business it supports.
S09
09

Quality assurance and testing

Testing strategy, automation, and manual verification of critical paths — done alongside implementation rather than after it.

Typical business needs
  • —A codebase with limited test coverage.
  • —Regressions appearing in areas that have not changed.
  • —Release cycles slowed down by manual verification.
Main deliverables
  • —Unit, integration and end-to-end tests where they matter most.
  • —Documented manual test procedures for high-risk paths.
  • —Continuous integration configuration that enforces quality.
Technical considerations
  • —Test coverage as a means to confidence, not a metric to optimise.
  • —Realistic test data that reflects production edge cases.
  • —Flakiness treated as a defect, not as background noise.
Expected business value
  • —The ability to change the system quickly without being afraid of it.
S10
10

DevOps and infrastructure support

Continuous integration and delivery pipelines, environment management and infrastructure as code, tied to the operational reality of the team.

Typical business needs
  • —Deployments that are slow, manual or error-prone.
  • —Environments that drift from one another over time.
  • —A team that wants to own its infrastructure rather than depend on unknown scripts.
Main deliverables
  • —Pipelines for build, test and deployment.
  • —Environment definitions checked into version control.
  • —Runbooks and monitoring dashboards for day-to-day operations.
Technical considerations
  • —Simplicity over completeness for a small team.
  • —Rollback strategy that is exercised, not just written down.
  • —Secrets and credentials handled with appropriate care.
Expected business value
  • —Shipping software as an ordinary, low-drama activity that the team can perform many times a day.
S11
11

Data-driven digital solutions

Data models, warehouses, analytics pipelines and internal reporting, designed so that the business can ask honest questions and get honest answers.

Typical business needs
  • —Data trapped in operational systems that were never designed to be queried.
  • —Reports that disagree with one another depending on their source.
  • —A decision that would be better supported by evidence than by intuition.
Main deliverables
  • —A defined data model shared across the organisation.
  • —Pipelines that move and transform data reliably.
  • —Dashboards or reports built on that model.
Technical considerations
  • —Data quality as an engineering responsibility, not a downstream complaint.
  • —Privacy and access carefully considered at each stage.
  • —Reproducibility of numbers, so that any metric can be audited.
Expected business value
  • —A single, reliable source of truth for the numbers on which the business acts.
S12
12

Ongoing software maintenance

Continued support of software already in production: monitoring, incident response, security updates, minor improvements and long-term evolution.

Typical business needs
  • —A system that must keep running long after the initial project ended.
  • —A small in-house team that cannot cover every technology it depends on.
  • —A desire for predictable operational costs.
Main deliverables
  • —A defined service arrangement with response expectations.
  • —Regular maintenance work: dependency updates, minor fixes, small improvements.
  • —Incident response with documented follow-up.
Technical considerations
  • —Boundaries between maintenance and new development, clearly agreed.
  • —Handover documentation kept current, not left to atrophy.
  • —Sustainable pace for the engineers doing the work.
Expected business value
  • —Software that continues to serve the business, as opposed to software that slowly drifts into a liability.
Interface engineering
Plate
Interface engineering
Drawn, measured, then coded.
Data architecture
Plate
Data architecture
Modelled before it is stored.
Implementation
Plate
Implementation
Tested as it is written.