My daughter was attending a concert at Forest National, which left me with a few hours to spend in Brussels.
The plan was simple: find a cinema, have something good to eat nearby and organise both efficiently enough to account for driving, parking and walking.
Brussels offered plenty of possible clusters.
What it did not offer nearly as consistently was clarity.
The first restaurant I considered had a website available only in French. That was not an insurmountable problem. I speak and read French fluently.
But it still raised an oddly persistent question:
Could I, as a Dutch-speaking visitor in Brussels, please receive some information in my own language?
A burger restaurant near a cinema looked like a practical alternative, but its online information made it difficult to understand exactly where the restaurant was and which page applied to that location. Several other websites followed. Some were incomplete in the selected language. Others made basic information harder to find than it should have been.
I eventually chose a brasserie where most of the information was available in the language I had selected. A few sections remained untranslated, but by then even that felt like progress.
The food was good.
I no longer remember which film I watched.
I do remember the websites.
The inconvenience was small. The question was not.
Nothing dramatic happened that evening.
I found somewhere to eat. I understood the French. I reached the cinema. No reservation system collapsed and no restaurant refused to serve me.
The friction was modest.
That is precisely why it was interesting.
A customer does not need to be completely blocked before a website begins losing value. Small uncertainties accumulate: an unclear location, an untranslated menu, an opening time that appears on one page but not another, a reservation button that leads somewhere unexpected, or a language selector that changes only half the page.
Each issue may look minor in isolation.
Together, they make a simple decision feel like work.
And I had an advantage. I speak French.
What is the experience for someone visiting from the United Kingdom, Germany, Scandinavia, the United States or elsewhere? What does an English-speaking expat find when searching for dinner near a concert venue? How confident is a tourist who only wants four basic answers?
- Where is the restaurant?
- Is it open?
- What kind of food does it serve?
- How can I reserve a table?
Brussels is officially bilingual in French and Dutch. It is also far more international than those two languages alone suggest. Official regional and tourism sources describe a city with more than 180 nationalities and over 100 languages spoken.
That does not mean every independent restaurant should maintain a perfect website in a dozen languages.
It does mean that the potential audience is unusually diverse.
The commercial question is therefore practical rather than political:
Can a potential customer understand enough to choose the business with confidence?
That evening, the answer was less consistent than expected.
This is not an article about language politics
Brussels has no shortage of political debates about language.
This is not one of them.
We are not trying to determine which language should dominate public life. We are not making legal claims about what every private restaurant must publish. We are not arguing that every small business needs a fully localised website for every nationality that may pass through the city.
The starting point is much more ordinary.
A restaurant website exists to help people decide whether to visit.
Language is one part of that job. So are location, opening hours, menus, pricing, reservations, mobile usability and trust.
A visitor who speaks French may still leave because the location is unclear. A Dutch-speaking local may leave because the selected language is incomplete. An international visitor may never reach the reservation page because the first screen gives no usable indication of what the restaurant offers.
The problem is not simply that a translation is missing.
The problem is that the digital journey may stop before the physical visit begins.
A physical cluster is not automatically a digital journey
My plan relied on a cluster.
The concert venue was fixed. I wanted food and a cinema within a practical radius. Driving, parking and walking time mattered. The evening only worked if the separate parts could be combined without unnecessary detours.
On a map, Brussels offered several options.
Online, those options were harder to evaluate.
This distinction matters for local businesses. A restaurant may sit in an excellent location near a cinema, concert venue, hotel, shopping centre or office district. That physical proximity creates an opportunity.
But the opportunity is only useful when customers can recognise it.
A restaurant can be perfectly located and still lose the decision online because:
- the official website is difficult to identify;
- different locations are presented inconsistently;
- the language options are incomplete;
- the menu is hidden in an awkward PDF;
- opening hours conflict across pages;
- the reservation flow is unclear;
- mobile navigation is frustrating;
- search results show outdated information;
- the website never explains why this location suits the visitor’s plan.
The business may see a functioning website.
The visitor experiences uncertainty.
That gap is where the Brussels Project begins.
One evening is not a market study
A personal experience can reveal a useful question.
It cannot prove how widespread the problem is.
It would be easy to turn one frustrating search into a sweeping conclusion about Brussels restaurants. That would be weak research and an unfair basis for approaching individual businesses.
So the next step is not to publish a list of offenders.
It is to investigate systematically.
The Brussels Project is Vayluna’s attempt to understand how local hospitality businesses present themselves online, where their websites create avoidable friction and which improvements might genuinely help both the business and the visitor.
Restaurants are the first focus because the decision journey is concrete.
A visitor typically needs to understand the offer, location, opening hours, menu, price level and reservation process. The outcome is also observable: either the website supports a decision or it leaves important questions unresolved.
Brussels is the first market because it combines local customers, commuters, tourists, expats, event visitors and business travellers inside a geographically compact region.
This is not intended to become another generic restaurant directory.
It is an operating project.
We are building a dedicated tool for it
Researching hundreds or thousands of businesses manually would quickly become repetitive and inconsistent.
A person can inspect a handful of websites carefully. At larger scale, the work becomes difficult to organise:
- finding the correct official site;
- recording available languages;
- checking whether translations are complete;
- locating menus, opening hours and reservation links;
- noting technical or mobile problems;
- preserving screenshots and evidence;
- separating real opportunities from minor imperfections;
- remembering which business has already been reviewed;
- preparing a relevant follow-up without turning it into generic spam.
That is why the Brussels Project is also becoming the first focused use case for a dedicated internal tool: the Vayluna Prospect Engine.
The tool is currently under development.
Its purpose is not to press one button and produce a sales list. It is to collect, structure and prioritise evidence so that a human operator can make a better decision.
The first version is being designed around a practical workflow.
What the tool should examine
1. Does the business have a usable official website?
The first task is identifying the correct business and its official online presence.
That sounds trivial until a restaurant has multiple locations, several social profiles, outdated directory listings, an old domain and different pages for delivery, reservations and the venue itself.
The tool should record what it finds without pretending that the first result is automatically correct.
2. Which languages are actually available?
A language selector alone proves very little.
The tool should distinguish between:
- a complete translated version;
- a partially translated version;
- navigation translated but content left unchanged;
- a separate menu available in another language;
- machine-translated fragments;
- no visible language option at all.
The question is not whether the website contains a flag icon.
It is whether a visitor can complete the relevant journey in the chosen language.
3. Is the practical information clear?
The system should look for the information a customer needs to act:
- address and location;
- opening days and hours;
- menu or food concept;
- indicative pricing;
- reservation method;
- telephone and contact details;
- accessibility or parking information when relevant;
- differences between multiple locations.
Missing information is one issue.
Conflicting information may be worse.
4. Does the website work properly on mobile?
Many restaurant searches happen while someone is already travelling, parking, walking or deciding where to go next.
A desktop-only experience is therefore not enough.
The tool should help identify layouts that break on smaller screens, unreadable menus, obstructive pop-ups, tiny buttons, slow pages and reservation flows that become difficult on a phone.
5. Are there technical and search problems?
A restaurant does not need an elaborate technical platform.
It does need pages that can be found, opened and understood.
The first version of the tool may flag issues such as:
- broken links;
- missing page titles;
- absent or duplicated descriptions;
- unsecured or inconsistent URLs;
- pages that cannot be indexed properly;
- old domains still appearing in search;
- missing local-business information;
- obvious loading or rendering failures.
These signals do not automatically justify a rebuild.
They create a reason to inspect the site more carefully.
6. Is there a genuine commercial opportunity?
Not every imperfection is a sales opportunity.
A small restaurant with a simple one-page site may already serve its customers perfectly well. A missing English page does not automatically mean the owner wants one. A dated design may be irrelevant when the restaurant is permanently full.
The engine should therefore help rank opportunities rather than merely count defects.
A meaningful opportunity may combine several factors:
- the business appears active;
- the current website creates visible friction;
- the location serves a multilingual or international audience;
- the problem can be demonstrated clearly;
- the improvement is realistic;
- Vayluna could offer a proportionate solution.
The final judgement remains human.
The tool should produce evidence, not accusations
There is a significant difference between these two messages:
Your website is bad and needs to be replaced.
and:
We noticed that the Dutch language option stops before the menu and reservation information. For a business near a major venue, that may create unnecessary friction for part of the local audience.
The first is generic prospecting.
The second is a specific observation that can be checked.
The Brussels Project should make the second type of communication possible.
That means preserving evidence: the relevant URL, the language selected, the page state, the missing information and the date of the observation. Websites change. Search results change. A problem seen today may be fixed next month.
The project should not present temporary findings as permanent truths.
It should also avoid publicly naming businesses merely to create dramatic examples. The restaurants that prompted this article remain anonymous because the purpose is to explain the pattern, not to embarrass individual operators.
If a specific business is contacted later, the evidence belongs in that private conversation.
Why this may eventually become part of the outreach
A useful article can do more than attract search traffic.
It can provide context.
Imagine receiving a message that says only:
We build multilingual websites for restaurants.
That could come from almost any agency.
Now compare it with a message that explains:
- the exact issue found on the site;
- why it matters for that location and audience;
- how the Brussels Project began;
- what the wider research is trying to understand;
- what a realistic correction could look like.
The article then becomes supporting material rather than bait.
A future message might say, in substance:
We noticed that your website does not currently provide the menu and reservation information in Dutch. We are researching how Brussels hospitality businesses serve multilingual visitors online, and this article explains why we started. We also believe the issue on your site could be fixed without turning the project into an unnecessary full rebuild.
That is still outreach.
It should not pretend otherwise.
But it is more useful than a mass email containing a recycled compliment, an invented urgency and a vague promise to “boost your online presence”.
The intention is to reach fewer businesses with more relevant observations.
Human approval remains part of the process. The tool may help collect information and prepare drafts, but messages should not be sent simply because an automated score crossed a threshold.
Why restaurants are only the beginning
The first version focuses on restaurants and hospitality because the customer journey is easy to understand.
The broader problem is not limited to food.
Similar gaps can appear on the websites of:
- independent hotels;
- cultural venues;
- shops serving tourists;
- local attractions;
- health and wellness businesses;
- professional services;
- event spaces;
- businesses with several Brussels locations.
The same core questions return.
Can people find the correct information?
Can they understand it?
Can they act on it?
Does the website reflect the audience the business actually serves?
Expanding too early would weaken the project. A tool that scans every type of local business from the start would likely produce shallow and generic observations.
The restaurant use case gives us a narrower environment in which to develop the data model, scoring, review process and outreach standards.
The project can broaden later if the first version proves useful.
This is also a test of how we want to use AI
The Brussels Project connects directly to the way Vayluna approaches AI-assisted work.
In How to Use AI to Build a Website or Online Store (Without Letting It Take Over), we argued that AI is most useful when a person defines the objective, context and quality standard.
The same principle applies here.
AI can help:
- classify website content;
- compare language versions;
- extract practical information;
- organise observations;
- draft summaries;
- detect inconsistencies;
- prioritise records;
- prepare a first outreach draft.
It should not decide by itself that a business is deficient, that a website must be rebuilt or that an unsolicited message should be sent.
Automation can make the research faster.
It cannot make the judgement automatically fair.
The value of the Prospect Engine will depend less on how many websites it can process than on whether it helps us identify real, defensible opportunities without losing the context of each business.
Where the Brussels Project stands today
At the time of writing, the dedicated tool is still being built.
The first work involves defining the fields, sources, audit criteria, evidence model and review process. The initial version will not understand every restaurant perfectly. Some websites will block automated inspection. Some language structures will be ambiguous. Some findings will require manual verification.
That is expected.
A first version is useful when it creates a repeatable workflow and reveals where the assumptions were wrong.
The project will begin narrowly, with controlled batches and human review. We will learn which signals matter, which create false positives and which improvements are realistic enough to mention to a business.
Only then does outreach make sense.
Publishing this introduction before the system is finished may seem early.
It is also honest.
The Brussels Project did not begin with a polished product presentation. It began with a parent trying to combine dinner and a film during a concert.
The evening worked.
The digital journey did not work as smoothly as it should have.
That was enough to start asking better questions.
A website should make the next step easier
A local business website does not need to impress everyone.
It does need to help the right person take the next step.
For a restaurant, that may mean understanding the menu, confirming the location and booking a table. For a visitor in Brussels, language and clarity are not decorative extras. They are part of whether the business feels accessible at the moment a decision is being made.
The Brussels Project will test how often that journey breaks and whether a dedicated tool can help us identify the businesses where a practical improvement would make a real difference.
Perhaps the strongest opportunities will be multilingual rebuilds.
Perhaps they will be much smaller: correcting a location page, completing one translation, simplifying a reservation flow or making a menu usable on mobile.
We do not know yet.
That is why we are building the tool.
Not to automate a conclusion.
To investigate the problem properly.
