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

NUEVAS TECNOLOGIAS TURISTICAS SL era una societat mercantil espanyola amb domicili registral a Las Palmas i adscrita al Registre Mercantil de Las Palmas. D'acord amb la fitxa registral publicada a OpenMercantil a partir del BORME, la societat s'emmarca en el sector del software i SaaS aplicat al turisme.

La informació disponible no permet determinar la seva mida, el seu volum de negoci, la seva plantilla ni el detall de la seva oferta. Aquestes dades no consten a la font consultada.

La societat es va constituir l'any 2026. La font registral consultada no recull la data exacta de constitució, els socis fundadors, el capital social inicial ni l'objecte social literal. Aquestes dades no consten.

Segons la classificació sectorial de la fitxa registral, l'empresa operava en l'àmbit del software i els serveis SaaS. La ubicació a Las Palmas és coherent amb un entorn econòmic fortament orientat al turisme, però la font no especifica quins productes o serveis concrets oferia ni a quin tipus de client s'adreçava. Aquest detall no consta.

No consta. La societat es va constituir i es va extingir dins del mateix any 2026, de manera que la font disponible no permet identificar cap període d'activitat consolidada, creixement o resultats positius.

D'acord amb el BORME, la societat es va dissoldre per fusió, amb extinció de la societat. La inscripció consta amb data de 18 d'agost de 2026 i fa referència a l'assentament registral número 2 del tom 8, full GC 24506 (12.08.26).

La font registral indica el mecanisme jurídic —la fusió amb extinció de la societat absorbida— però no identifica l'entitat absorbent, ni les condicions de la fusió, ni si hi va haver continuïtat del negoci sota una altra forma jurídica. Aquestes dades no consten a la font consultada.

No consta. La font disponible no permet afirmar si el negoci, la cartera de clients o la tecnologia de la societat es van traslladar a l'entitat resultant de la fusió, ni si hi va haver continuïtat operativa sota una altra denominació.

No consta. La fitxa registral consultada no identifica els socis fundadors ni els administradors de la societat, de manera que no es pot traçar la seva trajectòria posterior. Per completar aquesta informació es podria consultar el Registre Mercantil de Las Palmas (full GC 24506), la certificació de l'acord de fusió dipositada al registre i el BORME de la data de la inscripció, on habitualment consten les societats participants en la fusió.

• En el sector del software turístic, la constitució d'una societat i la seva extinció per fusió dins d'un mateix exercici és un senyal que cal llegir el projecte com una operació societària i no com un cicle de vida empresarial complet. Cal verificar sempre l'entitat absorbent abans de treure conclusions sobre la continuïtat del negoci.
• La ubicació a Las Palmas situa la societat en un mercat dominat per operadors turístics i intermediaris hotelers; en aquest context, la integració dins d'un grup més gran és una via habitual de consolidació per a projectes de software petits.
• Per a l'anàlisi de qualsevol empresa del sector, la fitxa registral per si sola no permet valorar l'activitat real: cal creuar-la amb el dipòsit de comptes, les notes de fusió i les fonts sectorials.

El que se sap del cert és mínim: una societat mercantil amb seu a Las Palmas, sector software i SaaS, constituïda el 2026 i extingida el mateix any mitjançant una operació de dissolució amb fusió inscrita al BORME el 18 d'agost de 2026 [BORME / BOE via OpenMercantil, 2026-08-18]. Una fusió no és un fracàs comercial: és una operació societària, i sovint el negoci continua dins d'una altra societat. Això vol dir que no podem afirmar que el projecte morís; només que aquesta persona jurídica va deixar d'existir.

Per tant, la "idea avui" no es pot derivar de l'empresa. S'ha de proposar. La proposta que faig, coherent amb el nom i el sector, és: un SaaS vertical per a operadors turístics petits i mitjans de Canàries — reserves, canal directe, facturació i comunicació amb l'hoste en un sol producte, amb compliment normatiu espanyol (facturació electrònica, registre de viatgers) integrat de sèrie.

Això és una proposta meva, no un fet verificat. El nom "Nuevas Tecnologías Turísticas" és genèric i no permet inferir el producte real.

El mercat que es pot afirmar sense inventar res és el context: Canàries és una destinació turística de primer ordre i té un teixit dens d'allotjaments petits (apartaments turístics, cases rurals, petits hotels, gestors de diverses unitats). Aquest segment és el que pitjor cobert està pels grans PMS internacionals, per cost i per complexitat.

El que no puc afirmar: quants operadors hi ha, quina quota està lliure, quins competidors locals hi ha, ni quin era el nínxol que aquesta empresa atacava. Són dades que caldria validar amb:

• Registre de Turisme de Canàries (nombre d'establiments per illa i tipologia).
• Enquestes a 20-30 gestors d'allotjament (estimació de mostra, a validar).
• Anàlisi de preus públics dels PMS SaaS existents al mercat espanyol.

Fins que això no estigui fet, qualsevol afirmació de mida de mercat seria inventada.

Proposta (no verificada): subscripció SaaS per unitat d'allotjament, amb tres nivells.

• Pla bàsic: gestió de reserves i calendari. Preu estimat: 15-25 €/mes per unitat (rang a validar amb el mercat).
• Pla professional: canal directe, motor de reserves propi, facturació. Estimat: 35-60 €/mes per unitat.
• Pla gestor: per a qui gestiona 5-50 unitats, amb multi-propietat i informes. Estimat: 80-150 €/mes per compte, més un mòdul per unitat.

Ingressos addicionals possibles: comissió per reserva processada (estimat 0,5-1,5%, a validar), serveis d'implantació i migració de dades (estimat 200-800 € per client), i integracions de pagament amb marge compartit.

El punt crític del model: el cost d'adquisició. Un SaaS vertical per a negocis petits ven per confiança i boca-orella, no per màrqueting digital massiu. Això afavoreix un model d'entrada molt assistida, encara que sembli poc escalable al principi.

Proposta en quatre fases, amb terminis estimats:

1. Mesos 0-3 — Validació. 25 entrevistes a gestors d'allotjament a Gran Canària i Tenerife (mostra estimada, a validar). Objectiu: confirmar quin és el dolor més car de resoldre. No escriure codi encara.
2. Mesos 3-6 — Prototip funcional. Un sol mòdul (el dolor confirmat), amb 5-8 clients pilots que paguin poc o res a canvi de feedback setmanal.
3. Mesos 6-12 — Producte mínim venible. Reserves + facturació + compliment normatiu. Objectiu estimat: 30-50 clients de pagament (a validar).
4. Mesos 12-24 — Expansió. Resta de l'arxipèlag i, si el producte ho permet, mercat peninsular i Balears. Objectiu estimat: 150-250 comptes (a validar).

Un criteri de parada honest: si al mes 9 no hi ha 20 clients que paguin sense descompte, el producte o el segment estan mal triats.

Tot són estimacions, a validar amb pressupostos reals:

• Equip fundador (2 persones, 12 mesos, sou modest): 60.000-90.000 €.
• Desenvolupament (si no el fa el fundador): 40.000-80.000 € per al producte mínim.
• Constitució, legal i compliment (RGPD, facturació electrònica, contractes): 5.000-10.000 €.
• Infraestructura i eines (primer any): 3.000-6.000 €.
• Màrqueting i vendes inicials (fires, contingut, prospecció): 10.000-20.000 €.
• Coixí (6 mesos de marge): 15.000-30.000 €.

Total estimat: 130.000-235.000 € per als primers 12-18 mesos. És un rang ampli perquè depèn de si el fundador programa o no. Una versió molt més barata (un fundador que programa, clients pilots, zero màrqueting) podria situar-se per sota dels 60.000 €, però amb més risc i més lentitud.

• Risc de fonament: no sabem què feia aquesta empresa. Reconstruir "la mateixa essència" és impossible amb les dades disponibles; el que aquí es proposa és una idea nova amb el mateix paraigua sectorial. Cal dir-ho clarament a qualsevol inversor o soci.
• Risc de mercat: el segment petit és fragmentat i té poder de negociació baix, però també capacitat de pagament baixa i alta rotació.
• Risc de competència: els grans PMS baixen de preu i els channel managers ocupen la porta d'entrada. Un producte nou ha de guanyar en una cosa molt concreta.
• Risc de compliment normatiu: facturació electrònica i registre de viatgers canvien; mantenir-se al dia és cost permanent, no un projecte.
• Risc d'equip: dos fundadors amb un producte de 18 mesos és el pitjor escenari per a la motivació. Cal un soci comercial, no només tècnic.

Les lliçons que es poden extreure de l'expedient original són poques però clares, i totes són sobre el contenidor, no sobre el contingut:

1. Una societat no és un projecte. Aquesta empresa va desaparèixer com a persona jurídica per fusió, no consta cap indici de fallida. Qui llegeixi "tancada" i conclogui "fracàs" s'equivoca. La primera lliçó és de lectura: distingir extinció registral de fracàs comercial.
2. Constituir i extingir el mateix any és una operació, no un cicle. En 2026 hi ha constitució i dissolució-fusió. Això suggereix una estructura creada per a una operació concreta o absorbida ràpidament. La lliçó: no construeixis una empresa al voltant d'una estructura si l'estructura és el producte.
3. El nom diu poc. "Nuevas Tecnologías Turísticas" és una declaració d'intenció, no una proposta de valor. La lliçó per a qui ho torni a fer: el nom ha de dir a qui serveix i per a què, o el mercat no ho recordarà.
4. Qui ho hauria de fer avui: un equip de 2-3 persones amb un fundador que conegui el negoci turístic canari de primera mà (no només el programari) i un altre que sàpiga vendre porta a porta. Sense aquesta combinació, el producte serà correcte i invisible.

I una advertència final, que és la més important: aquest informe no reconstrueix NUEVAS TECNOLOGIAS TURISTICAS SL. Proposa una empresa nova inspirada en el seu sector i la seva ubicació, perquè l'expedient verificat no conté prou informació per fer res més. Qualsevol pla que afirmi el contrari estaria inventant.

Els operadors petits de turisme actiu (kayak, rutes guiades, busseig, excursions) venen places per canals diversos —web pròpia, telèfon, OTAs, hotels intermediaris— i sovint sobrevenen o perden vendes perquè l'inventari no és compartit. A més, quan hi ha intermediaris, la conciliació de comissions i liquidacions es fa amb fulls de càlcul, cosa que genera errors i disputes.

El producte resoldria dues coses alhora: (1) una única font de veritat de disponibilitat per franja horària i recurs, amb reserva atòmica per evitar sobrevenda; i (2) un registre de moviments econòmics (ledger) que permeti saber, per a cada reserva, quant es cobra, quant es paga a l'intermediari i què queda pendent de liquidar.

Nota de context: la societat inspiradora consta com a extingida per fusió ([BORME / BOE via OpenMercantil, 2026-08-18] — https://openmercantil.es/empresa/nuevas-tecnologias-turisticas-sl). Per tant, aquesta especificació no descriu un sistema existent heretat, sinó un disseny nou; qualsevol afirmació sobre el negoci original més enllà de la dada registral seria una suposició.

Arquitectura de tres serveis desplegables per separat, tots amb Postgres 16 com a base de dades:

• inventory-svc: gestiona recursos (guies, embarcacions, places) i franges (slots). És l'únic servei que pot modificar comptadors de places.
• booking-svc: orquestra la reserva. Crida inventory-svc per retenir places i escriu la reserva en una transacció pròpia.
• ledger-svc: registra apunts econòmics immutables per reserva i calcula saldos per contrapart.

Motiu de separar inventory de booking: el bloqueig d'inventari és el punt de contenció; aïllar-lo permet escalar-lo i reiniciar-lo sense afectar el flux de reserves. Motiu de fer el ledger append-only: la conciliació requereix auditabilitat i reversibilitat sense esborrar història.

Flux de reserva (descripció textual):

``` client → booking-svc: POST /bookings booking-svc → inventory-svc: POST /holds {slot_id, qty, ttl=10m} inventory-svc: UPDATE slot SET held = held + qty WHERE slot_id=$1 AND capacity - held - confirmed >= qty ├─ si 0 files afectades → 409 SOLD_OUT └─ si ok → retorna hold_id booking-svc: INSERT booking (status=PENDING_PAYMENT, hold_id) booking-svc → client: 201 {booking_id, expires_at} ... pagament confirmat ... booking-svc → inventory-svc: POST /holds/{hold_id}/confirm inventory-svc: held -= qty; confirmed += qty (transacció única) booking-svc: UPDATE booking status=CONFIRMED booking-svc → ledger-svc: POST /entries (idempotency_key=booking_id) ```

Els holds expiren per un job intern d'inventory-svc que allibera places cada minut; el TTL és curt (10 min) per no bloquejar inventari en abandonaments de carret.

Esquema principal a Postgres. Les taules crítiques:

```sql -- inventory-svc CREATE TABLE resource ( id UUID PRIMARY KEY, operator_id UUID NOT NULL, name TEXT NOT NULL, timezone TEXT NOT NULL DEFAULT 'Atlantic/Canary' );

CREATE TABLE slot ( id UUID PRIMARY KEY, resource_id UUID NOT NULL REFERENCES resource(id), starts_at TIMESTAMPTZ NOT NULL, ends_at TIMESTAMPTZ NOT NULL, capacity INT NOT NULL CHECK (capacity >= 0), held INT NOT NULL DEFAULT 0 CHECK (held >= 0), confirmed INT NOT NULL DEFAULT 0 CHECK (confirmed >= 0), CONSTRAINT no_overbook CHECK (held + confirmed <= capacity), UNIQUE (resource_id, starts_at) );

CREATE TABLE hold ( id UUID PRIMARY KEY, slot_id UUID NOT NULL REFERENCES slot(id), qty INT NOT NULL CHECK (qty > 0), expires_at TIMESTAMPTZ NOT NULL, status TEXT NOT NULL CHECK (status IN ('ACTIVE','CONFIRMED','EXPIRED','RELEASED')) ); ```

La restricció `no_overbook` és la garantia última contra sobrevenda, fins i tot si hi ha un error de codi. Motiu: les comprovacions a nivell d'aplicació no són fiables sota concurrència.

```sql -- booking-svc CREATE TABLE booking ( id UUID PRIMARY KEY, slot_id UUID NOT NULL, hold_id UUID NOT NULL, customer_email TEXT NOT NULL, qty INT NOT NULL, status TEXT NOT NULL CHECK (status IN ('PENDING_PAYMENT','CONFIRMED','CANCELLED','EXPIRED')), channel TEXT NOT NULL, -- 'web','ota:getyourguide','hotel:xyz' created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); ```

```sql -- ledger-svc CREATE TABLE entry ( id BIGSERIAL PRIMARY KEY, booking_id UUID NOT NULL, account TEXT NOT NULL, -- 'operator:uuid','channel:ota','platform' amount_cents BIGINT NOT NULL, -- signe: + ingressa, - surt currency CHAR(3) NOT NULL DEFAULT 'EUR', kind TEXT NOT NULL CHECK (kind IN ('SALE','COMMISSION','REFUND','PAYOUT')), idempotency_key TEXT NOT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT now(), UNIQUE (idempotency_key, account, kind) ); ```

L'`idempotency_key` evita duplicar apunts si booking-svc reintenta la crida. El ledger no té UPDATE ni DELETE: les correccions es fan amb apunts compensatoris.

APIs internes (REST/JSON, autenticació per token de servei):

• `POST /holds` → `{slot_id, qty, ttl_seconds}` → `201 {hold_id, expires_at}` o `409 SOLD_OUT`.
• `POST /holds/{id}/confirm` → `200` o `410 HOLD_EXPIRED`.
• `POST /holds/{id}/release` → `204`.
• `POST /bookings` → crea reserva i reté places en una sola operació de cara al client.
• `POST /entries` (ledger) → `201`, idempotent per clau.

Integracions externes previstes, per fases:

1. Pagaments: Stripe Checkout o Redsys (merchant a Espanya). Motiu: Stripe redueix temps d'integració; Redsys és habitual en operadors locals i pot ser requisit comercial.
2. Canals OTA: adaptadors per GetYourGuide i Viator via les seves APIs de disponibilitat/reserva. Motiu: són els canals amb més volum per a activitats turístiques.
3. Webhooks de sortida: notificació de reserva confirmada/cancel·lada a sistemes de l'operador (email transaccional, Google Calendar per guies).

Cada adaptador de canal ha de traduir el seu model de disponibilitat al nostre `slot`; es documenta un contracte comú `ChannelAdapter` amb mètodes `pushAvailability`, `receiveBooking`, `ackBooking`.

Ordre deliberat, perquè cada peça desbloqueja la següent:

1. inventory-svc amb holds i la restricció `no_overbook`, més tests de concurrència. Sense això, res més no és fiable.
2. booking-svc amb el flux PENDING_PAYMENT → CONFIRMED i expiració de holds.
3. Pagament amb Stripe en mode test i webhook de confirmació.
4. ledger-svc amb apunts SALE i COMMISSION i un informe de saldos per contrapart.
5. Panell mínim de l'operador: veure franges, reserves i saldos.

Els connectors OTA i la facturació formal queden fora del primer abast: afegeixen complexitat contractual i no validen la hipòtesi central (inventari compartit sense sobrevenda).

• Concurrència d'inventari: el risc principal és la sobrevenda per condicions de cursa. Es mitiga amb l'UPDATE condicional i la restricció de base de dades; cal provar amb càrrega concurrent (p. ex. 200 reserves simultànies sobre una franja d'1 plaça).
• Holds orfes: si booking-svc cau després de retenir, el TTL els allibera; cal monitorar el nombre de holds ACTIVE per detectar fuites.
• Zones horàries: els slots es guarden en UTC i es mostren en `Atlantic/Canary`; els canvis d'hora poden duplicar o perdre franges si es generen per regla recurrent. Cal validar-ho amb tests de DST.
• Ledger i devolucions: les cancel·lacions requereixen apunts REFUND i possiblement PAYOUT negatiu; el disseny ha de suportar saldos negatius per contrapart.
• Volum esperat: per a un operador petit, centenars de reserves/dia; el sistema ha de suportar pics de 10-20 req/s amb marge. No cal sharding inicialment.
• Compliment: dades personals de clients (RGPD) i conservació de factures; el ledger ha de permetre exportació per a gestoria.

• Tests de concurrència automatitzats sobre inventory-svc: N reserves simultànies contra una capacitat C; el resultat ha de ser exactament min(N, C) confirmades i cap sobrevenda.
• Tests d'idempotència al ledger: repetir `POST /entries` amb la mateixa clau no crea duplicats.
• Tests de DST per a la generació de franges a l'octubre i març.
• Prova pilot amb un operador real (1-2 recursos, 2 setmanes) mesurant: reserves perdudes per sobrevenda (objectiu 0), temps de confirmació (<2 s p95) i diferències de conciliació (objectiu 0 €).
• Criteri d'èxit del pilot: cap incidència de sobrevenda i conciliació quadrada al 100% al tancament de les dues setmanes.

Fonts: la dada de dissolució prové de [BORME / BOE via OpenMercantil, 2026-08-18] — https://openmercantil.es/empresa/nuevas-tecnologias-turisticas-sl. La resta de l'especificació és disseny proposat i no afirma fets sobre l'empresa original.