Kurtaxe Self-Service

Inspiration

We own an apartment in Leukerbad that we rent through Airbnb and Booking.com. Like every accommodation provider, we are responsible for registering guests and handling the local tourist tax. What should be a simple administrative process quickly became one of the most frustrating parts of hosting. The existing software is built around legacy workflows. Guest information has to be collected manually, transferred between different systems, checked repeatedly, and entered into interfaces that were not designed for modern short-term rentals. We initially thought this was only a local problem. After speaking with other landlords and looking at other Swiss tourism destinations, we realised that the same issue exists across many municipalities. Different regions use different systems, but the experience is often the same: fragmented processes, repetitive data entry, unclear responsibilities, and frustrated accommodation providers. Landlords dislike the process, guests do not understand why they must enter the same information repeatedly, and municipalities receive incomplete or inconsistent data. That experience inspired Kurtaxe Self-Service.

The Problem

Tourist-tax administration in Switzerland is highly fragmented. Each municipality may have its own:

• tourist-tax regulations;
• guest registration workflow;
• software provider;
• required data fields;
• exemption rules;
• guest-card process;
• operational procedures. Replacing these systems would require significant public investment, complex procurement, migration projects, and years of implementation. At the same time, accommodation providers need a better experience today. The challenge is therefore not simply to build another tourist-tax system. The challenge is to create a modern and scalable user experience while continuing to work with the infrastructure municipalities already use. ## Our Solution Kurtaxe Self-Service provides a shared digital layer between guests, accommodation providers, tourism organisations, and municipal legacy systems. Landlords create their property once and send guests a registration link before arrival. Guests enter their information through a simple mobile interface. The platform validates the data, identifies missing information, applies municipality-specific rules, and prepares the registration for the existing backend process. With the landlord's explicit consent, the platform can complete the required workflow on their behalf. The user experience remains consistent:
• Open the registration link.
• Enter the guest information.
• Review and confirm the data.
• Complete the tourist-tax registration. Behind this simple process, the platform supports different municipal rules and technical systems through configurable workflows and reusable integration components. ## How We Built It We designed the project as a scalable platform rather than as a single-purpose integration for one municipality. The architecture separates three layers: ### 1. Shared User Experience The guest and landlord experience is independent of the municipality's backend system. This allows us to improve the interface, introduce automation, and optimise conversion without changing each municipal integration individually. ### 2. Municipality-Specific Business Rules Local regulations are represented as configurable requirements, including:
• mandatory guest information;
• tourist-tax rates;
• age-based exemptions;
• arrival and departure rules;
• accommodation categories;
• guest-card eligibility;
• consent and confirmation steps. ### 3. Legacy Integration Layer Municipality-specific adapters connect the platform to existing systems and workflows. Instead of requiring municipalities to replace their software, Kurtaxe Self-Service acts as a compatibility and orchestration layer around it. This model allows the platform to scale: $$ \text{Platform Value} = \text{Shared UX} + \text{Reusable Infrastructure} + \sum_{i=1}^{n}\text{Municipality Adapter}_i $$ As the number of supported municipalities grows, the shared platform becomes more valuable without requiring the entire product to be rebuilt for every destination. ## What We Learned The most important lesson was that the real problem is not only outdated software. It is fragmentation. A technically modern system can still create a poor experience when guests, landlords, tourism organisations, and municipalities all follow different processes. We also learned that municipalities do not necessarily need a complete system replacement. In many cases, they need a better layer around their existing infrastructure. This changes the economics of digitalisation. Instead of financing a large replacement project, a municipality can introduce a modern service incrementally. Existing investments remain usable, while landlords and guests receive a much better experience. Another important lesson was that the landlord is a critical actor in the process. The platform must not remove landlords from the workflow. It must give them control, transparency, and the ability to authorise automation on their behalf. Trust, consent, and auditability are therefore core product requirements, not optional features. ## Challenges We Faced ### Different Rules in Every Municipality Tourist-tax regulations vary significantly between destinations. A scalable platform must support local differences without turning every municipality into a completely separate software project. We addressed this by separating shared platform capabilities from configurable business rules and technical adapters. ### Working With Legacy Systems Legacy systems often have limited APIs, inconsistent interfaces, and workflows designed for manual administration. The challenge was to modernise the process without depending on an immediate backend replacement. Our solution is an integration layer that can work with APIs where available and support controlled automation where modern interfaces do not exist. ### Data Quality Municipalities require accurate guest information, while guests expect a fast and simple registration process. Requesting too much information creates abandonment. Requesting too little creates additional work later. We therefore focus on progressive validation: asking only for necessary information, validating it immediately, and explaining clearly why it is required. ### Trust and Consent The platform processes personal guest data and may act on behalf of a landlord. This requires explicit consent, clear responsibilities, secure processing, transparent actions, and an auditable history of submissions. ### Building a Sustainable Business Model The value is distributed across several parties:
• landlords save administrative time;
• guests receive a better experience;
• municipalities receive higher-quality data;
• tourism organisations reduce support work. The business model must therefore align pricing with measurable operational value. Potential models include subscriptions per property, transaction-based fees per stay, and municipality-level platform agreements. ## Business Potential Thousands of accommodation providers across Switzerland face similar administrative processes. The platform can monetise the shared user experience and infrastructure while supporting local requirements through municipality-specific integrations. A simplified revenue model could be expressed as: $$ R = P \cdot S_p + B \cdot S_b + M \cdot S_m $$ where:
• $P$ is the number of registered properties;
• $S_p$ is the subscription revenue per property;
• $B$ is the number of bookings or stays;
• $S_b$ is the transaction revenue per booking;
• $M$ is the number of municipal platform agreements;
• $S_m$ is the average municipal service revenue. This creates recurring revenue while reducing administrative costs for the ecosystem. ## Our Vision We want Kurtaxe Self-Service to become the shared infrastructure layer for tourist-tax registration across Switzerland. Guests should not have to understand which legacy system a municipality uses. Landlords should not have to spend their evenings copying passport details into outdated forms. Municipalities should not have to replace their entire backend simply to provide a modern digital service. Our goal is simple: > One modern tourist-tax experience across Switzerland, connected to the systems municipalities already have.

Built With

• codex
• consent-management
• data-privacy
• docker
• govtech
• keycloak
• legacy-integration
• multi-tenant
• municipalities
• next.js
• openai
• playwright
• postgresql
• python
• react
• rest-api
• rpa
• saas
• stripe
• switzerland
• tourism
• tourist-tax
• traveltech
• typescript
• workflow-automation