I'm a solo developer based in Zeeland, The Netherlands. I've been building Odeva, a property management system for holiday parks, vacation rentals, and campgrounds. It's a headless-first tool that's built specifically for the small-to-mid independent operators that legacy PMS vendors ignore. Still deciding on open-sourcing the project.
The problem: Most park management software was built 10+ years ago, designed for enterprise procurement, not for the receptionist or park manager who might not need all the bells and whistles. A 50-unit holiday park ends up paying €15K-70K/year across their PMS, channel manager, payment processing, owner portal, guest app, accounting integrations, and the manual labor of making it all work together. Small parks just eat the cost or cobble together spreadsheets. The result is that no PMS wants to help the little guys, and you end up with a package that is too expensive for them.
What I've built so far (alpha since May 2026, in production with early users):
- Planning board with drag-and-drop, visual availability, group reservations
- Mollie + Stripe payments with automatic refunds
- Guest portal for self-service check-in/out
- Owner settlements and revenue reporting
- Night register export for Dutch municipality compliance
- App marketplace with public/authorized API keys, webhooks, and a public GraphQL API
- MCP endpoint so AI agents can discover and interact with the API
- Sales channels management (Booking.com, Airbnb sync groundwork is done, but no organizations are currently testing this)
- Stay rules, pricing overrides, option/reservation lifecycle
The API is public and documented. There's a WordPress plugin for parks that run on WP, and a drop-in JS widget for anything else. The admin is multilingual (EN/NL/DE). There's a basic web editor to get you started quickly as well.
One nerdy thing I'm particularly proud of: I open-sourced a Tax Conformance Kit (https://codeberg.org/odeva/tax-conformance-kit) for Dutch tourist tax. Tourist tax rules are municipality-level, change frequently, and nobody can explain them consistently.
The stack is Ruby/Rails API, Astro website on Cloudflare Workers, deployed via Kamal to a Tailscale network. So far I had no issues with feature creep, and I think this was the right choice. I might migrate to Bunny.net soon.
If it weren't obvious, I was kind of inspired by Shopify's stack. I have worked on platinum-level Shopify apps before, and got to learn about the internals at Shopify while doing so. I think they do a pretty good job there! Shopify handles similar issues well by letting you start small, and having you choose Apps, details etc. on the go. That way you can go vertical for any niche feature you need. Similarly, they provide metafields that you can design yourself, so I do not need to setup ~200 amenities.
My main motivator was that me building something I think this industry needs. It was a challenge to see when I would hit a wall. Currently that wall is a lack of testers :)
I'd love feedback from anyone who's built booking/reservation systems, dealt with hospitality software, or has opinions on headless PMS architecture. Also happy to talk about the tax conformance approach. I think the "legal rules as testable data" pattern has applications beyond tourist tax, but I might be biased.
Regarding features, there's a long long TODO.md, but my ears are always open for voices!
Site: https://www.odeva.app
API docs: https://www.odeva.app/docs/api/
Tax Conformance Kit: https://codeberg.org/odeva/tax-conformance-kit