Hospitality recruitment platform: how we built Talia Gastro

This article covers a real case of ours, in production and a resounding success: Talia Gastro (taliagastro.com), the website and recruitment and restaurant-opening consultancy platform of Talia Bergman, a hospitality operator in Madrid. It went live in May 2026 with two halves designed from day zero: a website that gets found on Google and in AI assistants, and a three-role platform with an explainable matching engine. What follows is the architecture, the design decisions, the real numbers and what we learned.

In this article:

• The problem: recruiting by hand does not scale
• What we built: two halves and three roles
• The explainable matching engine
• A website designed to be found
• How it is operated after launch
• The numbers
• What we learned
• How to approach a project like this
• Frequently asked questions

The problem: recruiting by hand does not scale

A restaurant recruitment consultancy lives off a process that is almost never systematized. Candidates arrive over WhatsApp or by referral, restaurants ask for staff by phone, the consultant cross-checks the two lists from memory, coordinates interviews by hand and only gets paid when a contract is signed. Every step depends on one person, and that person is the bottleneck.

Talia Bergman has more than ten years in demanding Madrid projects and two lines of business: recruitment for restaurants and hotels, and opening consultancy, largely for people coming from abroad to open in Madrid. Her brief was not "a website". It was a platform that digitized the matching between hospitality workers and restaurants looking for staff, and a digital presence that positioned her in her own voice, not with a consultancy template.

Three constraints shaped the design:

• The operator has to stay in the middle, without being in every step. She only gets paid on a signed contract, so the platform had to give her control over who gets proposed without forcing her to coordinate every interview by hand.
• Candidate personal data. CV, phone, date of birth: access had to be separated by role at the database level, not in the interface.
• Spanish compliance from day one. GDPR and LSSI, with legal notice, privacy policy and a defined data retention policy.

What we built: two halves and three roles

The platform runs on Next.js and Supabase (Postgres, Auth and Storage), deployed on Vercel. We chose that stack because it serves the public website as fast static pages and, in the same project, runs an application with authentication, database and files, with no separate backend to maintain.

Four architecture decisions that apply to any platform of this kind:

• 1. Row-level security in the database. Each user can only read and write their own rows, and Postgres guarantees that with access policies, not the interface code. A bug in a screen does not expose another candidate CV.
• 2. The candidate form is public and anonymous. A hospitality worker does not create an account to apply: they upload their data and CV, and the operator decides from her panel whether to promote them to the pool. It lowers friction on the side with the most volume.
• 3. Admin login by magic link to the business mailbox, with no password to lose.
• 4. Transactional notifications from the own domain: every candidate registration and every new restaurant request reaches the operator by email at the moment it happens.

The explainable matching engine

The heart of the platform is the matching: when a restaurant request is opened, the panel shows the position details on the left and the candidates ranked by fit percentage on the right, with a traffic light (green from 80 to 100%, yellow from 60 to 79%, orange below). The first version used five weighted criteria, defined with the operator before writing code:

Two decisions that matter more than the weights:

• Rules, not an opaque model. Every percentage is explained: the second version of the engine shows the reasons next to the number, and the operator adjusts the weights from her settings panel, with a change history. When a person is about to propose a candidate for a real position, they have to be able to defend why that one and not another.
• The matching ranks, it does not decide. The proposal to the restaurant is made by the operator, with one click. The system saves her the cross-check, not the judgment.

A website designed to be found

The other half of the project was the public website, and the rule was to do the SEO before designing, not after. Before writing a line of copy:

• Keyword research of the hospitality sector in Spain: 16 prioritized searches, classified by intent (restaurants looking for staff vs. workers looking for jobs) and assigned to each page.
• Analysis of 6 SERPs in the niche, to know who each page competes against and in what format.
• 6 SEO/GEO content pieces: 3 service pages and 3 articles with question-and-direct-answer structure and extractable FAQ, written in the operator editorial voice.

On the technical side, the site launched with 8 types of structured data (organization, person, services, articles, FAQ, breadcrumbs, website and local business), llms.txt, robots.txt open to AI crawlers, a dynamic sitemap, Open Graph and security headers. The exit technical audit scored 80 out of 100, with the weak points identified and fixed before launch. How we do this for any website is in our Claude Code development service.

How it is operated after launch

A platform that is delivered and abandoned degrades in weeks. Since August 2026 Talia Gastro evolves under a monthly plan, and that operation has three pieces already in production:

• Continuous integration with 80 automated test files (unit and end-to-end with Playwright), running on every change before reaching production. The first full CI run surfaced four defects no user had reported.
• Scheduled data-retention jobs: inactive profiles are notified and deleted according to the privacy policy, with no manual intervention.
• Matching engine adjustments based on what the operator sees in her panel, not on assumptions.

The rule of the plan is evolution on evidence: first measure what gets shown and what converts, then build.

The numbers

Impressions are from Google Search Console, reviewed with the client on September 15, 2026, with the hospitality season just starting and no paid ads. The other numbers come from the repository and the project documents.

What we learned

• 1. SEO from the design stage pays off in the first season. With no ads and four months live, the site is already shown 2,500 times a month on Google, almost all in Spain. A site designed first and optimized later takes much longer to get there.
• 2. A matching engine with explainable rules is worth more than a "smart" one. The operator understands it, adjusts it and defends it in front of the restaurant. An opaque model would have been more impressive in the demo and less useful the day someone has to be proposed.
• 3. What comes next is conversion. Google showing the site is half the job; the other half is the restaurant that sees it asking for staff. That is the work of the plan now: titles, descriptions and calls to action measured against Search Console, plus content that does the math on what a bad hire costs.

How to approach a project like this

If you have a recruitment, ordering or matching process that lives in WhatsApp and spreadsheets today, the order that works is:

• 1. Write down the process as it is today, with who does each step and where it gets stuck. The Talia Gastro requirements document came from that.
• 2. Define the roles and what each one sees. Permissions are designed before screens.
• 3. Decide the matching rules with whoever recruits, with explicit weights. They can change later; what you cannot do is start without them.
• 4. Do the keyword research before the design, so every page is born targeting a real search.
• 5. Launch with tests and a monthly evolution plan. A platform that is not operated degrades.

Frequently asked questions