NUEVAS TECNOLOGIAS TURISTICAS SL(R.M. LAS PALMAS)

NUEVAS TECNOLOGIAS TURISTICAS SL era una sociedad mercantil española con domicilio registral en Las Palmas y adscrita al Registro Mercantil de Las Palmas. De acuerdo con la ficha registral publicada en OpenMercantil a partir del BORME, la sociedad se enmarca en el sector del software y SaaS aplicado al turismo.

La información disponible no permite determinar su tamaño, su volumen de negocio, su plantilla ni el detalle de su oferta. Estos datos no constan en la fuente consultada.

La sociedad se constituyó en el año 2026. La fuente registral consultada no recoge la fecha exacta de constitución, los socios fundadores, el capital social inicial ni el objeto social literal. Estos datos no constan.

Según la clasificación sectorial de la ficha registral, la empresa operaba en el ámbito del software y los servicios SaaS. La ubicación en Las Palmas es coherente con un entorno económico fuertemente orientado al turismo, pero la fuente no especifica qué productos o servicios concretos ofrecía ni a qué tipo de cliente se dirigía. Este detalle no consta.

No consta. La sociedad se constituyó y se extinguió dentro del mismo año 2026, de modo que la fuente disponible no permite identificar ningún periodo de actividad consolidada, crecimiento o resultados positivos.

De acuerdo con el BORME, la sociedad se disolvió por fusión, con extinción de la sociedad. La inscripción consta con fecha de 18 de agosto de 2026 y hace referencia al asiento registral número 2 del tomo 8, folio GC 24506 (12.08.26).

La fuente registral indica el mecanismo jurídico —la fusión con extinción de la sociedad absorbida— pero no identifica la entidad absorbente, ni las condiciones de la fusión, ni si hubo continuidad del negocio bajo otra forma jurídica. Estos datos no constan en la fuente consultada.

No consta. La fuente disponible no permite afirmar si el negocio, la cartera de clientes o la tecnología de la sociedad se trasladaron a la entidad resultante de la fusión, ni si hubo continuidad operativa bajo otra denominación.

No consta. La ficha registral consultada no identifica los socios fundadores ni los administradores de la sociedad, de modo que no se puede trazar su trayectoria posterior. Para completar esta información se podría consultar el Registro Mercantil de Las Palmas (folio GC 24506), la certificación del acuerdo de fusión depositada en el registro y el BORME de la fecha de la inscripción, donde habitualmente constan las sociedades participantes en la fusión.

• En el sector del software turístico, la constitución de una sociedad y su extinción por fusión dentro de un mismo ejercicio es una señal de que hay que leer el proyecto como una operación societaria y no como un ciclo de vida empresarial completo. Hay que verificar siempre la entidad absorbente antes de sacar conclusiones sobre la continuidad del negocio.
• La ubicación en Las Palmas sitúa a la sociedad en un mercado dominado por operadores turísticos e intermediarios hoteleros; en este contexto, la integración dentro de un grupo más grande es una vía habitual de consolidación para proyectos de software pequeños.
• Para el análisis de cualquier empresa del sector, la ficha registral por sí sola no permite valorar la actividad real: hay que cruzarla con el depósito de cuentas, las notas de fusión y las fuentes sectoriales.

El que se sap del cert és mínim: una societat limitada anomenada "Nuevas Tecnologías Turísticas SL", domiciliada a Las Palmas, sector software i SaaS, que es va extingir per fusió el 2026. La fusió (no una liquidació) suggereix —és una lectura, no un fet— que el negoci o els actius es van integrar en una altra societat en lloc de tancar-se en sec. Això és tot el que el registre permet afirmar.

Per tant, "la idea, avui" no pot ser una continuació: ha de ser una proposta nova. La proposta és construir un micro-SaaS vertical per a operadors turístics de Canàries i mercats similars (reserves, channel manager lleuger, automatització de comunicació amb el client, facturació), venut per subscripció a pimes turístiques que avui fan servir fulls de càlcul i WhatsApp. És una hipòtesi de treball coherent amb el nom i el sector, i res més.

El mercat rellevant és el de programari de gestió per a allotjaments i activitats turístiques petits i mitjans: hotels rurals, apartaments turístics, cases rurals, empreses d'excursions i lloguers vacacionals. És un mercat real i gran, però molt competitiu i amb actors consolidats (channel managers i PMS internacionals) i molta oferta local.

El que sí que es pot afirmar amb seguretat: Canàries és una de les principals destinacions turístiques d'Europa i té un teixit dens de pimes turístiques. Això és context de mercat, no dada de l'empresa. Mida de mercat, quota assolible i disposició a pagar: a validar amb entrevistes abans de construir res.

Proposta: subscripció SaaS per establiment, amb tres plans (bàsic, professional, multi-propietat) i un mòdul de pagaments o comissions per reserva com a ingrés secundari.

• Preu orientatiu: rang estimat de 29–99 €/mes per establiment segons pla (a validar contra competidors).
• Ingrés secundari: comissió o marge sobre pagaments gestionats (a definir).
• Cost d'adquisició: vendre a pimes turístiques és intensiu en contacte humà; cal preveure venda directa i partenariat amb associacions i gestors.

No hi ha cap dada verificada sobre quin model feia servir l'empresa original; aquest és íntegrament proposta.

1. Fase 0 (4–6 setmanes): 15–25 entrevistes amb operadors turístics canaris per validar el problema concret i el preu. Cost: gairebé només temps.
2. Fase 1 (2–3 mesos): MVP d'una sola funció (per exemple, gestió de reserves i comunicació automàtica), amb 3–5 clients pilots.
3. Fase 2 (3–6 mesos): integracions amb els canals de distribució més usats i primeres subscripcions de pagament.
4. Fase 3: expansió a altres regions turístiques i a segments adjacents (activitats, restaurants).

Cada fase hauria de tenir un criteri d'aturada clar (per exemple: si després de la fase 1 cap pilot no paga, es replanteja).

Xifres orientatives, estimació a validar, per als primers 12 mesos:

• Constitució de societat i gestoria: rang estimat 600–1.500 €.
• Desenvolupament (1–2 persones, propi o extern): rang estimat 30.000–80.000 € si es contracta; molt menys si el fundador programa.
• Eines i infraestructura (hosting, APIs, correu, analytics): rang estimat 150–400 €/mes.
• Màrqueting i venda inicial: rang estimat 5.000–15.000 €.
• Legal (termes, privacitat, contractes): rang estimat 1.500–4.000 €.
• Marge de tresoreria per 12 mesos sense ingressos: rang estimat 10.000–25.000 €.

Total orientatiu: rang estimat de 50.000 a 120.000 € per al primer any, amb una versió "fundador que programa" molt per sota d'aquest interval. Són xifres de planificació, no cotitzacions.

• Risc de base: no hi ha informació pública sobre per què l'empresa original va desaparèixer ni què feia exactament. Qualsevol "reconstrucció" és especulació; el risc principal és construir sobre una narrativa inventada.
• Competència: el nínxol de software turístic està molt servit; cal un angle molt concret per diferenciar-se.
• Cicle de venda lent i baixa digitalització de moltes pimes turístiques.
• Dependència d'APIs de tercers (canals de distribució, pagaments), amb canvis de condicions freqüents.
• Estacionalitat del client turístic, que afecta la caixa.
• Risc de fusió mal interpretada: la dissolució per fusió pot significar que el negoci ja viu dins una altra societat; abans de reutilitzar el nom cal comprovar-ho al registre.

Lliçons que es poden extreure de l'expedient original, no un perfil de candidat:

1. El registre diu molt poc. D'una SL només sabem nom, sector, domicili i que es va extingir per fusió. Qualsevol informe de reconstrucció ha de començar reconeixent aquest límit.
2. Fusió no és fracàs. La inscripció de "Disolución. Fusion. Extinción" indica integració en una altra estructura; llegir-ho com a tancament pur seria un error d'interpretació.
3. El nom és l'única pista d'intenció. "Nuevas Tecnologías Turísticas" assenyala un sector, no un producte; qui vulgui reprendre l'esperit ha de validar el producte des de zero.
4. Qui ho hauria de fer és, per tant, algú disposat a validar abans de construir, amb coneixement real del turisme canari i capacitat tècnica o un soci que la tingui — i, sobretot, disposat a acceptar que la informació disponible no permet afirmar res més enllà del que diu el BORME.

Els operadors turístics petits (cases rurals, apartaments, petites agències d'activitats) venen per diversos canals alhora: web pròpia, Booking, Airbnb, GetYourGuide, telèfon i WhatsApp. Cada canal té el seu calendari i la seva política de cancel·lació. El resultat habitual és doble reserva, hores de conciliació manual en fulls de càlcul i una caixa que no quadra amb el que diu la plataforma.

La causa de tancament verificada d'aquesta societat va ser una dissolució per fusió [BORME, 2026-08-18], no un fracàs de producte: no hi ha evidència que el producte arribés a mercat. Per tant, el problema que es descriu aquí és el del nínxol, no una lliçó extreta de la seva fallida.

El que diferencia aquesta proposta d'un PMS genèric: inventari únic amb bloqueig transaccional per unitat i franja, i conciliació automàtica de liquidacions per canal. No és un channel manager més; és la capa que garanteix que el que es ven existeix i que els diners que entren es poden traçar.

Tres serveis i una base de dades, desplegats en un sol proveïdor cloud europeu (per RGPD i latència a Canàries).

``` [Canals externs] --webhooks--> [channel-gateway] --\ [Web pròpia / API] ----------> [booking-api] ------> [Postgres: inventari + reserves] [WhatsApp/telèfon] --> [backoffice] ---------------/ | v [settlement-worker] --> [informes / alertes] ```

• `booking-api`: rep reserves, valida i bloqueja inventari. Escrit en TypeScript sobre Node, perquè l'equip objectiu és petit i polivalent.
• `channel-gateway`: adaptador per canal (Booking, Airbnb, GetYourGuide). Cada canal és un mòdul amb la seva pròpia traducció de payload; el nucli no coneix cap canal. Motiu: afegir un canal no ha de tocar la lògica de reserves.
• `settlement-worker`: feina programada que descarrega liquidacions dels canals i les concilia contra les reserves. Aïllat perquè un canal lent no ha de bloquejar les vendes.
• Postgres: font única de veritat. L'inventari es bloqueja amb una transacció i una restricció d'exclusió per rang de dates, no amb comprovacions a l'aplicació. Motiu: el sobrebooking és el risc número u i no es pot confiar en un `SELECT` previ.

Entitats principals (simplificat):

```sql unit(id, property_id, name, capacity, base_price) availability(id, unit_id, daterange, source, hold_expires_at) -- EXCLUDE USING gist (unit_id WITH =, daterange WITH &&) booking(id, unit_id, channel, external_ref, guest_email, daterange, status, gross_amount, currency) settlement(id, channel, period_start, period_end, amount, imported_at) settlement_line(id, settlement_id, external_ref, booking_id, amount, match_status) channel_credential(id, channel, property_id, secret_ref, active) ```

Decisions:

• `daterange` amb `EXCLUDE` a Postgres: la base de dades mateixa impedeix solapaments. És l'única manera robusta de garantir-ho amb escriptures concurrents.
• `availability.hold_expires_at`: les reserves en curs (checkout no completat) bloquegen inventari temporalment. Sense això, dos usuaris poden pagar alhora.
• `settlement_line.match_status` ∈ `{matched, unmatched, disputed}`: la conciliació és explícita, no s'infereix.
• Els secrets de canal no viuen a la taula: `secret_ref` apunta a un gestor de secrets. Motiu: rotació de credencials sense migració de dades.

API pública (REST, JSON):

• `POST /v1/bookings` — crea reserva; retorna `409` amb el conflicte concret si l'inventari no està lliure.
• `GET /v1/units/{id}/availability?from=&to=` — consulta sense bloqueig.
• `POST /v1/holds` — reserva temporal d'inventari (TTL 15 min).
• `GET /v1/settlements/{id}/reconciliation` — estat de conciliació.

Integracions de canal: cada canal entra per webhook signat (HMAC) i es processa de manera idempotent per `external_ref`. Motiu: els canals reenvien esdeveniments; processar-los dues vegades no pot duplicar reserves.

Pagaments: Stripe per a la web pròpia; els canals cobren ells i liquiden. Això obliga el `settlement-worker` a tractar comissions i devolucions per separat.

WhatsApp: via API de negoci, amb un bot mínim que només consulta disponibilitat i crea `holds`; mai confirma pagaments. Motiu: reduir risc d'error en un canal informal.

1. Inventari transaccional + `POST /v1/bookings` amb la restricció d'exclusió. Sense això no hi ha producte.
2. Un sol canal integrat (el que tingui més volum per al client pilot) per validar el patró d'adaptador.
3. Backoffice mínim: veure reserves, bloquejar dates a mà, resoldre conflictes.
4. Conciliació de liquidacions d'aquell canal, encara que sigui amb revisió manual assistida.
5. Només després: segon canal, WhatsApp, informes.

Ordre motivat: cada pas és utilitzable sol i el següent no invalida l'anterior. La conciliació va abans del segon canal perquè és el que genera confiança i retenció.

• Mida: MVP viable amb 2-3 persones en 4-6 mesos. El coll d'ampolla no és el codi sinó les integracions de canal (documentació pobra, aprovacions llargues).
• Risc: canals que no permeten webhooks fiables → mitigació: polling de reconciliació periòdic a més del webhook.
• Risc: zona horària i canvis d'hora en rangs de dates → mitigació: tot en UTC a la base de dades, conversió només a la vista.
• Risc: latència des de Las Palmas → mitigació: desplegament a regió europea propera i CDN per a l'estàtic.
• Risc: dependència d'un sol proveïdor cloud → acceptat per a MVP; exportació de dades en format obert des del dia u.
• Risc legal: RGPD per dades de hostes i facturació intracomunitària; cal revisió abans de la fase 2.

• Test de concurrència: N escriptures simultànies sobre la mateixa unitat i dates; el resultat ha de ser exactament una reserva i N-1 conflictes `409`. S'executa a CI a cada merge.
• Test de idempotència: reenviar el mateix webhook 10 vegades no crea reserves duplicades.
• Pilot amb un operador real de Las Palmas durant 8 setmanes; mètrica d'èxit: zero sobrebookings i conciliació de liquidacions amb menys de 2% de línies `unmatched`.
• Mètrica de càrrega manual: hores/setmana dedicades a conciliar, mesurades abans i després. Objectiu: reducció ≥60%.
• Criteri de descart: si en el pilot les línies `unmatched` superen el 10% de manera sostinguda, el model de conciliació s'ha de redissenyar abans d'escalar.

Font: [BORME / BOE (via OpenMercantil), 2026-08-18] — https://openmercantil.es/empresa/nuevas-tecnologias-turisticas-sl