Before deciding, let’s make it clear.

YATH is a product and technology-solutions company. It builds its own vertical products and develops custom solutions when a problem does not fit them. It brings strategy, software, data, marketing, and implementation together under one direction.

None of those labels explains the whole model. We can work on strategy, product, development, and growth, but we do not sell isolated hours from a catalog. We start with a business problem and connect the capabilities needed to solve and implement it.

The Canary Islands are our initial market and where we can closely support certain implementations. Software, strategy, and part of the delivery can be provided elsewhere when the project, support, and local partners allow us to maintain quality.

The first family includes YATH Menu for visual menu experiences; YATH Screens, for managing content across private screen networks; and YATH Retail, for understanding commercial opportunities, decisions, and results across channels.

No. Access depends on the product, number of locations or screens, configuration, hardware, integrations, and implementation stage. A demo should lead to a proposal that clearly separates licensing, equipment, implementation, and additional services.

YATH Menu is sold as software. If the project also requires equipment, a complete solution can be coordinated from €2,490 plus applicable taxes, subject to configuration and quotation.

When the product architecture allows it, yes. Modularity should reduce complexity, not create an incoherent experience. The proposal defines which modules are active, what is ready, and what would depend on a later expansion.

Yes, when there is an advantage or need that should not be forced into an existing product. Before development, we define the problem, users, process, initial scope, evidence of success, and the cost of maintaining the solution.

We can assess it, but not every integration is technically or economically sensible. We review the API, permissions, data quality, provider limits, security, and maintenance before including it in scope and budget.

There is no single answer. A YATH product is licensed; an exclusive development may have a different arrangement; and reusable components require a specific definition. Ownership, license, code access, and rights to evolve it must be agreed before work begins.

It starts with a context conversation. If there is a fit, we move to diagnosis, solution definition, scope, proposal, and implementation. We do not start coding before we know what change the project must create and who will validate it.

It depends on scope, content readiness, hardware, integrations, validations, and client availability. Giving a generic date before reviewing those dependencies would be unreliable. The proposal should include phases, owners, and conditions that may change the timeline.

It does not mean getting a free product or accepting an unfinished one without terms. It is an initial implementation with controlled scope, close access to the team, and shared learning. Price, duration, support, usage data, and success criteria are agreed before we start.

It depends on the product and plan purchased. The channel, hours, response times, included maintenance, and changes requiring a budget must be defined. Support, product evolution, and custom development are not the same thing.

Only what is needed to provide the service, measure the agreed operation, or improve the product on a legitimate basis. The specific data depends on the solution. Purpose, access, retention, and responsibilities must be documented; information is not collected “just in case.”

Only with authorization and under agreed terms. We may measure non-invasive usage data to assess implementation, but publishing results, identifying the client, or turning them into commercial material requires specific permission and validated evidence.

In tasks where it reduces friction or improves capability: assisted translation, classification, controlled generation, analysis, or automation. It is not presented as an automatic substitute for human judgment, and its use must fit the risk, needed quality, and available data.