Restaurants, beach clubs and terraces · Marbella · 2026

One app for the host, the floor, the kitchen and management.

Each station sees the screen it needs, and all four say the same thing: who has arrived, where they are sitting, what they ordered and what is still to come out. It sits on top of your booking system and your POS, replacing neither.

Let's talk about a founding pilot → See the system

The app is built and working · not yet used in a venue · first season, a few venues

4screens, one per station
1record per party of guests
50automated tests, all passing
0systems you have to replace
The system, today

Four real captures: host, floor, kitchen and management

Not mockups. This is the application running, captured at the same moment from all four stations. No screen contradicts another.

Casa Azul · demonstration venue
Reception
  • Arrived with no table, waiting 60 minutes
  • Real floor plan: terrace, indoors and bar
  • Walk-ins become parties, not invented bookings
1 2 Reception view: floor plan with terrace, indoor room and bar, free and occupied tables, and an arrival with no table waiting to be seated.
Floor
  • "Add something off-menu…" — anything can be ordered
  • Every dish, with its kitchen status live
  • Correct or pull a dish already sent to the kitchen
3 4 Floor view: orders by party, menu by category, kitchen state of every line and a free-text field for ordering something off-menu.
Kitchen
  • Queued / preparing / ready, reversible
  • Ask the waiter on that table a question
  • Dark mode, so it reads on the pass
5 6 Kitchen view in dark mode: active orders by table with queued, preparing and ready states, and buttons to ask for clarification.
Management
  • Price pending on an off-menu request
  • What is outstanding, who has no table, what clashes
  • Replay the whole service, minute by minute
7 8 Management view: counters for open work, unassigned tables and conflicts, and a task pending a price for an off-menu request.
01The record travels with the party, not the table
02Anything off the menu can still be ordered
03Everything that matters can be undone
04Whatever did not go out is flagged
05Your team makes the decisions

This is what is built today, and we are looking for somewhere to run it. Talk about a pilot →

The gap

What changes at each point in a service

The six points where a service loses information. On the left, how it is handled today in most venues. On the right, what the system does.

Without the system
Walk-in arrivalWritten on paper, or remembered.
Table moveCalled out to whoever is nearby.
AllergyPassed on verbally, indistinguishable from a preference.
Status of a dishYou have to ask the kitchen.
Off-menu requestLeft unpriced, with nobody assigned to it.
End of serviceNo record of what happened.

The information lives in the shift's memory. At close, it is gone.

With the system
Walk-in arrivalA party is created with an arrival time; a booking attaches later if one shows up.
Table moveRecorded with time and author, and the record moves with the party.
AllergyIts own field, distinct from a preference, with an owner.
Status of a dishOn screen: queued, preparing or ready.
Off-menu requestBecomes a task with an owner until it is priced.
End of serviceA timeline that can be read back and cannot be rewritten.

Every change carries a time, an author and a recipient.

Your booking system Owns the book. Availability, new bookings and changes, cancellations, guest history.
Your POS Owns the money. Fiscally valid pricing, payments, tax, end-of-day close.
Us We run the live service. Who has arrived and where they are, the waits, the table moves, who owns each exception, and the record of what happened. If you change POS, we keep working.
One visit

One record per party of guests, from the booking until they leave

Almost all hospitality software is organised around tables, and a table changes hands several times a service. The people sitting at it do not. So the record travels with them: if they move to the terrace, their allergy and their order move too.

01ReservationThe odd request becomes a task
02ConfirmationIf the message never arrived, you see it
03ArrivalDifferent name, same party
04WaitWho quoted the wait, and when
05TableThey move and the record goes too
06ConflictTwo parties, one table: it warns, not blocks
07OrderOn the menu and off it
08HandoffOn record who collected it
Party · Ortega 5 people · at table
PlaceIndoor 14 → Terrace 3moved 22:04
ReservationUnder the hotel's name, attached laterup to date
RestrictionCoeliac — not a preferenceallergy
Order2 from the menu · 1 off-menu, no priceto price
KitchenMain ready, waiting to be collectedready
MessagesConfirmation delivered · reminder failed1 undelivered
POSLast sync 6 minutes agostale

The record all four stations open · schematic, not a screenshot

If you recognise these points in your own service, tell us how yours runs →

Where we are

What works today, what is designed and what is untested

It has not yet been through a real season in a venue. That is why we are looking for pilots, not customers.

Works today
  • The four screens, one per station
  • The party record and its timeline
  • Arrival, wait, table, order, kitchen, handover
  • Walk-ins, table moves and clashes, all recoverable
  • Off-menu orders, with the kitchen able to query them
  • Correcting and reopening anything that matters
  • Keeps working with no internet and syncs on reconnect
  • 32 logic tests + 18 browser tests
Not yet proven
  • A real service in a real venue
  • Peak-hour traffic
  • Paying customers
  • Measured savings
  • Live integrations with a POS or reservation system
  • Case studies or references
Reasonable doubts

What people ask us.

Almost all of them are about what we do not do.

No. Your reservation system still owns the book. We take that context and handle what happens after the plan meets reality: arrival, wait, table, handoffs and exceptions.
No. We carry the operational context of the order and the kitchen state, but your POS remains the fiscal authority over prices, payments, tax and invoicing. We touch none of that.
It is designed to work alongside existing reservation systems and POS, but we have no production integrations yet and we are not going to show logos we have not earned. With the pilot venues we decide together which ones to start with. In the meantime the system runs without depending on any of them.
It stays yours. In a pilot you are the data controller and we are only the data processor: we do not use it to train models and we do not cross it with data from other venues. We sign the Article 28 GDPR processing agreement before a single real record goes in. Allergies are health data, the system tells them apart from a preference, and they are handled under your responsibility. Detail in section 06 of the privacy policy (ES).
Accepted actions are stored on the device and resent when the connection returns, without duplicating. If reality changed in the meantime, the conflict is reviewed instead of overwritten. Said honestly: verified locally, not in a real service yet.
Because they work, and that is why they are the real competitor. What they do not keep is who owns it, whether anyone has seen it, the context when a party changes table, or what was decided in the end. If our system is slower than a shout, the team will shout. And they will be right.
Voice can be a way in later on. The product is the shared operational reality: the thing that lets the team, the automation and one day the voice act on the same information.
That is the bar: if an action needs someone to explain how it is done, it is badly designed. Each view shows only what that role needs, and everything important can be undone, so getting it wrong is not frightening. In a pilot we are on the floor for the first services.
Agreed case by case, depending on the size of the venue and how involved you want to be in the product. We do not publish pricing yet: doing that before a real venue has used it for a season would be making it up.
We would rather say it now:
  • Small venue, fixed tables and a team of three who can see each other: coordinating out loud already works for them.
  • If the goal is to cut headcount. This replaces nobody.
  • If you need something proven in twenty venues. We do not have that yet and we are not going to pretend otherwise.
Investors We are at product stage, before the first pilot. We will tell you where we really are, including what does not work yet. danylo@vektora.es → Partners and referrers If your clients have this problem every Friday. Operations consultants, POS installers and restaurant groups in Marbella. danylo@vektora.es →
Founding pilot

We are looking for a few pilot venues in Marbella

Restaurants, beach clubs and terraces in Marbella where service goes off script often: walk-ins, table moves, off-menu requests, large parties. In exchange for coming in early, you get direct access to us and a vote on what we build next.

01Half an hour on a call. You tell us how your service runs and where it breaks.
02We show you the system with an example service, from reservation to close.
03If it fits, we define the pilot. If not, we say so on the call.
Email us → Message on WhatsApp
Loading calendar…

Prefer to write? +34 633 18 77 82 · @vektora.es

Danylo Vorobiovskyi
Strategy · Electronic Eng.
Adam Ehmidi
Systems · Computer Eng.

There are two of us. Adam builds it, Danylo talks to the venues, and when you write, one of the two replies. No venue has run it for a full season yet, so in a pilot we are on the floor for the first services — not on the other end of a phone.