Kemp Starý Sad: From a pre-season rescue to a custom reservation system

I took over Kemp Starý Sad just as the new season was approaching and the launch was only days away. The site was partly built, but it was missing a number of key features it couldn't go live without.

The main goal was to get the project into production as fast as possible, enable reservations, and create a stable base for further development.

The biggest challenge wasn't the development itself — it was time. The reservation system had to be running within days, and it needed reliable technical foundations. The project required:

I took a pragmatic approach: instead of a long build of a complex system, ship a working MVP as fast as possible — one that could accept reservations and comfortably handle the opening season. Within days an email-based reservation system was live, letting operations start immediately without waiting for an extensive admin or complex integrations.

In parallel I finished the frontend, optimised performance, added basic SEO, set up hosting, configured data storage and made security adjustments. The result was a successful launch before the season began.

After the MVP came a second phase focused on long-term sustainability and the operator's efficiency. The original solution became a full reservation web application. A custom admin replaced the Directus headless CMS; it includes a visual map of camp pitches for quickly assigning stays, an occupancy calendar and a daily operations view with arrivals and departures.

Today the admin covers the whole lifecycle of a stay: confirmation, pitch assignment, extending or ending a stay early, and cancellation with a reason and a message to the guest. The system closes finished stays on its own and cancels reservations left unhandled for too long. New views come with a short walkthrough, so even someone opening the admin for the first time can find their way.

The booking form was fully redesigned around real-time availability. The guest first picks dates and an accommodation type (caravan, tent, motorhome). The calendar immediately blocks fully booked nights and types that have no space left.

The system checks more than total capacity. It makes sure at least one pitch stays free for the whole stay and limits the latest possible departure accordingly. Overlapping reservations are guarded by both the application and a database constraint, so the same pitch can't be sold twice, even when bookings arrive at the same time.

The operator can close the camp on selected days in the admin, for an event or a holiday. The form then blocks those days automatically and the admin lists the affected guests who need to be contacted. Outside the season the site switches to an "end of season" mode with reservations turned off.

The site is bilingual (Czech and English), including the booking flow, legal pages and emails. It has a granular cookie banner and conversion tracking.

At the end of the first season a statistics page was added. It shows occupancy, nights and guest counts, a comparison with previous years, an occupancy heatmap and a breakdown by accommodation type and booking source (the website, or entered manually by the operator). Statistics can be filtered by month and type and exported to CSV and Excel. The data is processed without guests' personal details.

After launch it turned out the server side was running in the US while the database lived in Frankfurt. Every query crossed the Atlantic and the admin was needlessly slow. We moved the application to Frankfurt, into the same data centre and private network as the PostgreSQL database, with a CDN in front of it.

Database latency dropped from tens of milliseconds to single digits, and the database is no longer reachable from the public internet. We also shut down an unused Directus instance, so the move came without a significant rise in monthly costs. Deployments run automatically from GitHub, and scheduled jobs handle nightly maintenance.

After the season the application was hardened:

In line with GDPR, the system automatically anonymises personal data from reservations that never took place after 12 months, and from completed stays after three years. Statistical data is preserved. The retention periods are published in the privacy policy.

We continue to develop the project. The MVP built in a few days is now a stable system. More than 500 reservations went through it in the first season; it saves the operator time in day-to-day management and its statistics inform planning for the seasons ahead.