Refúgio da Azinheira: the arithmetic of direct booking
A countryside retreat on Portugal's N2 that now takes bookings with no middleman. The website is the easy part. The hard part is what happens next.
A rural guesthouse that lives off booking platforms has a quiet problem: it does not own the relationship with the guest. It has no email address, it does not choose the message, it cannot set its price without penalty, and it hands a slice of every night to whoever arranged the introduction.
Refúgio da Azinheira sits on the N2, in the Alentejo. We built its website, and the goal was never "to have an online presence". It was to change who controls the booking.
A beautiful website sells nothing
This is where most projects fail. Somebody builds an elegant site, full of sunset photographs, and then the visitor clicks "book" and lands on a form promising a reply within 24 hours.
Nobody waits 24 hours. In those 24 hours, that person has already booked elsewhere, because elsewhere answered in ten seconds.
A direct booking only exists if the path from "I like this" to "it is booked" is shorter than on the platform. Not equal. Shorter.
What that requires, in practice
Real availability, on screen. A calendar showing what is free, now, without a phone call. If the visitor has to ask whether there is a room, you have already lost them.
Calendar synchronisation. This is the detail that separates a serious project from a brochure. If direct bookings do not talk to platform bookings, the inevitable result is the double booking: two families, one night, one bed. A mistake like that costs more than every commission you saved.
WhatsApp, not a form. In local accommodation, the conversation is the channel. People want to ask whether pets are welcome, whether there is shade, whether the gate opens at night. A form kills that conversation; WhatsApp lets it happen on the phone, where the person already is.
Five languages. The N2 is an international route. A German visitor landing on a Portuguese-only site does not hesitate: they go back to the platform, which speaks their language. The site speaks Portuguese, English, Spanish, French and German, and not out of vanity. Out of conversion.
What was built, and with what
Scope. Institutional site and direct booking engine for a single guest house, in five languages, with live availability and synchronisation against the platforms.
| Application | ASP.NET Core, served by Kestrel |
| Hosting | Azure App Service |
| Internationalisation | 5 languages (PT, EN, ES, FR, DE), full hreflang and x-default |
| SEO | BedAndBreakfast structured data with coordinates and address, so Google shows the house as accommodation rather than as just another page |
| Bookings | availability calendar and iCal synchronisation with the platforms |
| Contact | WhatsApp directly, not a form |
The hreflang is not decoration. The N2 is an international route. Without it, Google shows the Portuguese page to a German visitor, and that visitor goes back to the platform, which is in his language. The five languages exist for conversion, not for vanity.
The iCal synchronisation is the heart of it. It is what prevents the double booking: two families, the same night, the same bed. One of those costs more than every commission saved in a year.
What changes when it works
The commission you save is the first thing you see, and it is the least interesting part.
What really changes is that the house now holds its guests' contact details. It can write to them in winter. It can offer them a return visit without paying anyone for the privilege. It stops renting the relationship and starts owning it.
You do not kill a fly with a cannon
There was a version of this project with a headless CMS, a SPA on top, an API in the middle and microservices flirting in the distance. It would have looked good in a slide deck.
It was not built, and the reason is simple: a guest house is not a hotel chain. The content changes half a dozen times a year. The operation is one person with a phone. Every extra piece would be one more thing to maintain, to patch and to break, and it would bring the guest nothing they could see.
What was built is an ASP.NET Core application on Azure App Service, with HTML rendered on the server. Boring, solid, and cheap to run.
The hard engineering is not choosing the bigger technology. It is choosing the smallest one that solves the problem, and being able to defend it. It is easier to justify a cannon to a client than to explain why they do not need one.
What we do not promise
We do not promise the platforms stop being useful. They are, and they keep bringing people who have never heard of the house.
The aim is not to leave them. It is to stop depending on them alone. And for that, the website has to be as fast and as reliable as they are. Nothing is left to chance.
It is live at refugioazinheira.pt.
