Konoba Plavi Kamen: designing for tourists who haven't arrived yet

A restaurant in the middle of a city competes with whatever's within walking distance. A konoba on the island of Cres competes with a decision someone made from their hotel room, in a language that might not be theirs, before they ever saw the building.

That's the problem Konoba Plavi Kamen — one of our own coastal hospitality concepts — was built to solve. Not "make a nice website for a restaurant." Make a website that does the convincing before the tourist shows up.

Why this is a different brief than a city restaurant

Tourists deciding where to eat on a coastline aren't browsing a neighborhood. They're often deciding from somewhere else entirely — scrolling hotel recommendations, searching in a language that isn't their first, trying to get a feel for a place they've never physically stood in. A city restaurant can lean on foot traffic and local reputation. A seaside konoba can't. The website has to do more of the convincing, faster, in more than one language.

So the brief wasn't "build a restaurant site." It was: show the atmosphere immediately, work properly in at least three languages, and get someone from "I'm thinking about it" to "I've requested a table" without friction.

What we built, and why

Three languages, built in from the start — not bolted on. Croatian, English and German, because that's the realistic spread of who's actually deciding where to eat on that coastline. Multilingual UX done properly means the German version isn't a stiff translation of the English one; it's treated as a first-class path through the site, with its own URL per language and proper hreflang annotations so a German search for a Cres restaurant actually surfaces the German page — not the English one with a flag icon bolted on.

Stone, sea, slow afternoons — as a visual system, not a mood board. The coastal identity had to come through in the layout and photography choices themselves, not just in a few hero images. If the rest of the site feels generic, one good photo doesn't rescue it.

A booking system we built ourselves, not rented. This is the decision I'd point to first. We used Next.js with Supabase to build a lightweight, custom reservation system rather than embedding a third-party booking widget — Postgres underneath, with row-level security doing the work of making sure a request for one table can't read or touch anyone else's, instead of us hand-rolling that check in application code where it's easier to get wrong. Two reasons we built rather than bought: third-party booking platforms usually take a commission on every table they fill, and they rarely match the visual language of the site they're bolted onto — you'll notice the seam immediately. Building it ourselves meant zero commission on table requests, and a booking flow that actually looks like it belongs on the page instead of an iframe pretending to.

The tradeoff worth naming

Building your own booking system instead of using an off-the-shelf one is more work upfront. There's no vendor handling edge cases for you. We think that tradeoff is worth it specifically for a business where every table matters and every euro of commission is real money leaving a small operation — which describes most coastal hospitality businesses, not just this one.

What actually made this hard

Not the code. The hard part was resisting the instinct to add more — more sections, more copy, more "trust us" badges. A tourist deciding where to eat tonight isn't going to read three paragraphs about your sourcing philosophy. They're going to look at a handful of photos, check if there's an English menu, and decide in under a minute. Every piece of this site was edited against that minute, not against what felt thorough to build.

That's the real lesson from this one: for a seaside business, your website isn't a brochure. It's the last five seconds of a decision someone's already half-made. Build for that five seconds, not for the version of the visitor who wants to read your whole story.