RELEASE-UNO devuelve una portada impecable. Detrás, API-PIZARRA ha dejado de actualizar FICHA-BASALTO, DEP-CENIZA no tiene owner, el rollback apunta a una build incompatible y las credenciales viven en una cuenta que controla el proveedor. La captura de pantalla sigue pareciendo un éxito.
El desarrollo web inmobiliario se compra como un sistema operable. Código, feeds, CMS, infraestructura, permisos, pruebas, despliegues, observabilidad, restauración y mantenimiento deben llegar con versiones y responsables. La interfaz aprobada por ES-181 es una entrada; no sustituye la evidencia de implementación.
ES-182 compara cinco proveedores mediante el Dossier Sala de Máquinas. Todo el laboratorio es sintético. La prueba observa cómo una agencia convierte especificaciones aprobadas en software, controla cambios, maneja estados de datos, conserva evidencia técnica y entrega el sistema sin abrir cuentas o tocar propiedades reales.
Real Estate Webmasters abre la lista por publicar custom websites, MLS integration y una plataforma inmobiliaria. Union Street Media conecta plataforma, IDX y gestión de listings, leads y agents. Luxury Presence une web personalizada, plataforma e IDX. AgentFire presenta una plataforma web, opciones fully custom e integrations. Agent Image publica modelos custom, semi-custom, Agent Pro y opciones IDX.
El orden reconoce ajuste del alcance publicado al pilot, no calidad técnica, seguridad, cumplimiento o resultado. Las fuentes de OWASP, NIST, Google, W3C, AEPD y RFC Editor convierten temas amplios en controles y preguntas. Ninguna evalúa a estas empresas ni aprueba la metodología.
theStacc publica y edita ES-182, vende servicios de marketing digital y los promociona mediante los llamados a la acción de esta página. theStacc no figura entre los proveedores, no recibe puntuación y ningún proveedor pagó por inclusión o posición. La investigación se cerró el 31 de agosto de 2026 después de abrir doce fuentes oficiales: las páginas de Real Estate Webmasters, Union Street Media, Luxury Presence, AgentFire y Agent Image; OWASP ASVS y OWASP Logging Cheat Sheet; NIST SP 800-218 Secure Software Development Framework; Google Web Vitals; WCAG 2.2 de W3C; la guía de privacidad desde el diseño de la AEPD; y RFC 9110 sobre semántica HTTP. Las páginas empresariales demuestran únicamente el alcance que cada empresa declara. No contratamos servicios, pedimos propuestas, verificamos equipos, revisamos contratos, entrevistamos clientes, auditamos repositorios, ejecutamos código, conectamos MLS o IDX, creamos cuentas, cargamos inmuebles, configuramos nube, DNS o hosting, almacenamos secretos, instalamos dependencias, desplegamos releases, medimos rendimiento o accesibilidad, ejecutamos pruebas de seguridad, recogimos logs, restauramos backups, atendimos incidentes, exportamos datos ni cambiamos de proveedor. No verificamos trabajo en España, español nativo, personal, subcontratistas, disponibilidad, precios, plazos, soporte, calidad de código, propiedad, licencias, cumplimiento, privacidad, seguridad, accesibilidad, fiabilidad, rendimiento, uptime, mantenimiento, portabilidad o resultados. Excluimos testimonios, clientes, premios, antigüedad, cifras promocionales, puntuaciones, tráfico, leads, captaciones, citas, ventas, alquileres, ingresos, conversiones y ROI. El Dossier Sala de Máquinas usa BUILD-COBRE, una compilación sintética; API-PIZARRA, un contrato de feed que no resuelve un endpoint; FICHA-BASALTO, un inmueble ficticio sin persona, dirección, precio o medio; SECRETO-NULO, una referencia sin valor; DEP-CENIZA, una dependencia imaginaria; RELEASE-UNO, un despliegue simulado; INCIDENTE-PULSO, un incidente de laboratorio; y RESTORE-LINO, una restauración abstracta. No contiene marca, empresa, persona, propiedad, ubicación, cuenta, token, contraseña, clave, cookie, formulario, fichero, imagen, pago o dato personal real. No toca CMS, repositorio, dominio, DNS, nube, hosting, CDN, MLS, IDX, CRM, analytics, correo o sistemas externos. Esta página no ofrece asesoramiento inmobiliario, jurídico, de privacidad, accesibilidad, seguridad, ingeniería o cumplimiento, ni presenta una referencia técnica como garantía universal. Antes de contratar o publicar se requieren una persona responsable de negocio inmobiliario en España, asesoramiento jurídico español, revisión de privacidad y protección de datos, revisión técnica y de seguridad, revisión de accesibilidad de implementación, evaluación independiente de desarrollo web y revisión de español nativo, todos con nombre, alcance y aceptación documentados. ES-181 conserva investigación de usuario, arquitectura de información, wireframes, interfaz, sistema de diseño, decisiones de accesibilidad en diseño y derechos de contenido o medios. ES-182 recibe versiones aprobadas y conserva implementación, código, integraciones y feeds, infraestructura, environments, despliegue, operaciones de seguridad, evidencia de rendimiento, technical handover, mantenimiento y salida. ES-177 conserva URLs, facetas, canonical, sitemap, indexación y Search Console. ES-180 conserva paid, CRM, atribución y handoffs entre canales. Faltan revisores nombrados, owner técnico permanente, owner de mantenimiento y aceptación responsable. ES-182 permanece needs_human_review y no debe publicarse hasta documentarlos.
La respuesta corta
Real Estate Webmasters presenta el ajuste documental más próximo para una inmobiliaria que necesita web personalizada, integración MLS y plataforma dentro de un mismo alcance publicado. Union Street Media, Luxury Presence, AgentFire y Agent Image ofrecen combinaciones distintas. La compra debe probar repo, feed, environments, deploy, logging, restore, mantenimiento, revocación y exit con registros ficticios.
- Real Estate Webmasters: equipos que buscan una web personalizada conectada a MLS y quieren evaluar en un mismo pilot código, integración, plataforma y operación
- Union Street Media: inmobiliarias que necesitan IDX, listings y agent management dentro de una plataforma y pueden auditar la dependencia y exportabilidad de cada módulo
- Luxury Presence: equipos que quieren una web personalizada dentro de una plataforma editable y necesitan aceptar técnicamente el contrato entre IDX, CMS y frontend
- AgentFire: agentes y equipos que quieren comparar configuración y construcción personalizada dentro de una plataforma con addons, integrations y MLS coverage publicados
- Agent Image: compradores que quieren definir la frontera técnica entre desarrollo propio, configuración de plantilla y servicios IDX antes de contratar
El Dossier Sala de Máquinas empieza donde termina el prototipo
ES-181 entrega un Design Handoff con versión aprobada, tipos de página, componentes, estados, tokens, contenido permitido, decisiones accesibles, derechos pendientes y criterios visuales. ES-182 no rediseña esos elementos en silencio. Abre un change request cuando una restricción técnica exige otra decisión.
Implementation Acceptance Map transforma cada requisito aprobado en componente o servicio, repo path propuesto, environment, test, owner, evidence y estado. Una pantalla que se parece al mockup puede fallar si el orden del DOM, el foco, el error, el dato o la recuperación no coinciden.
BUILD-COBRE es una compilación ficticia con Build-ID, source revision, dependency snapshot, configuration reference, artifact hash pendiente, environment target, test summary y approval state. No contiene código ni apunta a un repositorio real.
Repository Contract identifica organización propietaria propuesta, repositorio, visibilidad, ramas, merge checks, roles, backup, export, issue tracker, release tags, retention question y termination. La herramienta concreta permanece abierta; la prueba busca control institucional y un historial transferible.
Contribution Workflow conserva change ID, branch, reviewer type, tests, security question, accessibility question, migration impact, approval y merge evidence. Nadie inventa nombres de reviewers. Un cambio urgente también necesita autor, motivo, diff, decisión y revisión posterior.
Build Reproducibility Record pregunta qué inputs necesita BUILD-COBRE, qué versiones quedan fijadas, qué elementos llegan desde services externos, qué artifact se produce y cómo se verifica. La comparación no afirma reproducibilidad hasta que otro entorno obtenga evidencia equivalente.
DEP-CENIZA representa una dependencia inexistente. Dependency Inventory registra nombre, versión, fuente, licencia pendiente, uso, owner, direct o transitive state, advisory process, actualización, sustitución, build impact y exit. No atribuye vulnerabilidades reales.
Un Software Materials Export puede tomar la forma que el equipo técnico apruebe. Debe permitir localizar DEP-CENIZA, relacionarla con BUILD-COBRE y saber qué releases la incorporan. El artículo no prescribe un formato ni llama SBOM a cualquier lista sin procedencia.
NIST SP 800-218 publica Secure Software Development Framework Version 1.1 como recomendaciones para reducir el riesgo de vulnerabilidades en software. ES-182 usa esa referencia para preguntar por preparación, protección, producción y respuesta sin declarar que una checklist demuestre seguridad.
OWASP ASVS ofrece una lista de requisitos para desarrollo seguro y verificación de controles técnicos. Security Control Matrix selecciona requisitos con un especialista, enlaza cada uno a componente, amenaza considerada, test, environment, evidence, defecto, owner y retest.
Architecture Record separa frontend, CMS, property feed, search, media, forms, CRM handoff, cache, jobs, storage, auth, monitoring y third parties. Cada relación tiene protocolo, data class, failure mode, timeout question, retry question, owner y exit dependency.
API-PIZARRA es un contrato abstracto sin hostname. Define request shape, response shape, version, authentication reference, pagination question, rate-limit question, cache behavior, error taxonomy, retry condition, idempotency question, logs y deprecation notice.
RFC 9110 define la semántica de HTTP. ES-182 la entrega al equipo técnico para revisar métodos, respuestas, status handling, metadata, caching y conditional requests cuando corresponda. Esta página no diseña una API ni generaliza una respuesta para todos los casos.
FICHA-BASALTO contiene Property-ID, source version y estados sintéticos. No incluye dirección, precio, coordenadas, descripción, persona o media. Fixture Pack crea versiones complete, partial, withdrawn, duplicate, delayed, malformed y unavailable para probar mapping y degradación.
Feed Mapping Table enlaza source field, target field, type, transformation permitida, unknown state, validation, owner, version y removal behavior. ES-182 implementa el mapping. ES-181 decide cómo se presenta un estado aprobado y ES-177 revisa efectos orgánicos de URLs e indexación.
Feed Freshness Record guarda source observation, received time, processed time, display version, queue state, error, retry, alert y owner. El laboratorio usa timestamps ficticios sin calcular latencias o SLA. Una tarjeta visible no demuestra que la ficha esté vigente.
Withdrawal Test cambia FICHA-BASALTO a withdrawn en el fixture. El sistema propuesto debe detener nuevas publicaciones dependientes, actualizar cache, invalidar vistas, registrar consumers y conservar evidencia. ES-182 no decide la respuesta legal o comercial.
Data Migration Plan relaciona source record, target record, mapping version, validation, exception, rollback, reconciliation, owner y acceptance. Una importación completa en número de filas puede seguir equivocada en relaciones, estados o codificación.
CMS Integration Contract documenta content types, fields, validation, permissions, preview, versioning, publish, unpublish, locale, webhooks, export y deletion question. ES-181 posee el modelo y la interfaz editorial aprobados; ES-182 demuestra su implementación y recuperación.
Form Delivery Contract recibe field schema y microcopy aprobados. ES-182 implementa validation, transport, failure state, spam control question, privacy handoff, recipient, queue, logging exclusions, deletion path y test. El pilot no envía formularios ni contiene datos personales.
AEPD publica una guía de privacidad desde el diseño. Privacy Implementation Map vincula data flow, component, environment, log, access, third party, retention question y deletion question con revisión jurídica y de privacidad. El equipo técnico no decide la base legal.
SECRETO-NULO es una referencia sin valor. Secret Register guarda purpose, environment, system owner, reader role, writer role, rotation trigger, revocation, backup question y incident link. Nunca almacena passwords, tokens, private keys o valores de producción.
Environment Matrix separa developer workstation, preview, integration, staging y production con data policy, network boundary, access, secrets source, services, deployment path, logs, monitoring y cleanup. Ningún entorno del dossier existe fuera del documento.
Configuration Contract distingue valor público, configuración por environment y secret reference. Cada campo tiene schema, default permitido, validation, owner y change history. Una variable ausente debe fallar de forma prevista, no activar una configuración silenciosa.
Account and Access Register cubre repo, cloud, registrar, DNS, CDN, CMS, monitoring, error tracking, storage, email y third parties. Para cada sistema registra organization owner, backup admin, agency user, role, purpose, review, expiry, recovery y revocation.
Infrastructure Decision Record conserva service, need, options, constraint, data region question, availability design, backup, scaling question, cost owner, exit path y reviewer. ES-182 no inventa topología, región o proveedor de nube.
Infrastructure as Code queda como pregunta contractual. Si existe, el proveedor muestra repositorio, state handling, approvals, plan evidence, drift detection, secret references, rollback y export. Si no existe, documenta cómo otro equipo reconstruye la configuración sin memoria oral.
Domain and DNS Runbook separa registrar, nameservers, records, certificate flow, email dependencies, verification records, change authority, backup, lock question, recovery y exit. La inmobiliaria necesita ownership institucional documentado aunque la agencia opere cambios.
Deployment Pipeline Record enlaza source revision, BUILD-COBRE, tests, artifact, environment, approvals, migration, deploy action, smoke test, monitoring window, rollback target y outcome. No presupone continuous deployment ni recomienda automatizar una decisión sensible.
RELEASE-UNO es una release simulada. Su Release Manifest incluye Build-ID, configuration schema, dependency export, database change question, content compatibility, feed contract version, known issues, approvers pendientes, rollback target y support owner.
Release Gate acepta passed, failed, blocked o not_applicable con evidence. Diseño y accesibilidad reciben sus inputs desde ES-181; ES-182 aporta DOM, interaction y test evidence. Privacidad, seguridad, negocio inmobiliario y técnica conservan decisiones separadas.
Google Web Vitals presenta LCP, INP y CLS como métricas para carga, interacción y estabilidad visual. Performance Evidence Pack define page type, fixture, device, network, tool, run conditions, result, distribution question, budget, regression y owner sin inventar thresholds.
El budget también puede cubrir server timing, asset size, cache, image delivery, JavaScript, CSS y third parties si el equipo los aprueba. Cada límite necesita contexto y medición repetible. Una cifra de laboratorio no se convierte en experiencia universal.
WCAG 2.2 organiza criterios de conformidad para contenido web accesible. ES-181 conserva decisiones y especificaciones de accesibilidad en diseño. ES-182 produce evidencia de implementación sobre markup, nombre, rol, estado, teclado, foco, errores, reflow y comportamiento dinámico.
Accessibility Implementation Record no declara conformidad por una prueba automática. Conserva criterio seleccionado, component version, fixture, manual step, tool signal, evidence, defect, owner y retest para que una persona especialista decida.
Browser and Runtime Matrix combina browser engine, viewport, input, feature, page type, feed state, form state y expected behavior. Un screenshot no cierra un defecto de navegación, hidratación, cache o error recovery.
Test Portfolio separa unit, component, contract, integration, end-to-end, accessibility, performance, security y restore checks. Cada suite tiene scope, fixture, environment, trigger, owner, evidence, flake handling y retention. La comparación no afirma coverage porcentual.
OWASP Logging Cheat Sheet aborda eventos que registrar, atributos, datos que excluir, collection, verification, protection, monitoring y operación. Logging Contract adapta esas preguntas con revisión de seguridad y privacidad. No copia requests completos ni secrets por defecto.
Event Taxonomy distingue build, deploy, authentication, permission change, feed error, job failure, content publish, form failure, security signal, backup y restore. Cada evento tiene purpose, fields, excluded data, severity proposal, owner, retention question y alert route.
Trace and Correlation Plan define IDs sintéticos entre request, feed job, content version y release. No usa persona, property address o email como correlation key. El equipo de privacidad revisa cualquier identificador antes de producción.
Monitoring Contract separa availability, latency, error rate, feed freshness, job backlog, form delivery, certificate, DNS, resource saturation y third-party failure. Cada señal tiene source, threshold question, receiver, escalation, runbook y evidence.
Service-Level Proposal permanece sin cifras hasta que negocio y técnica aprueben scope, measurement point, exclusions, maintenance, reporting y remedy. El artículo no presenta uptime, response time o resolution time como hecho.
INCIDENTE-PULSO combina feed stalled, stale cache y failed job en sistemas ficticios. Incident Record contiene detection, classification propuesta, affected release, scope, owner, stop authority, evidence freeze, actions, communications, recovery y review.
Rollback Test mueve RELEASE-UNO hacia una release abstracta anterior. Comprueba code, configuration, database compatibility question, queue state, cache, feed version, smoke tests y monitoring. No promete duración ni toca producción.
RESTORE-LINO representa una restauración sin datos. Backup and Restore Record registra system, scope, method, encryption question, access, schedule proposal, retention question, restore environment, validation, owner y evidence. Un backup no está probado por existir en un panel.
Disaster Scenario retira un servicio ficticio y un account owner. El equipo debe recuperar documentación, configuration, artifacts, data snapshot abstracto y access path con backups institucionales. El ejercicio no afirma resiliencia hasta superar revisión independiente.
Maintenance Matrix separa defect, dependency, vulnerability, feed change, CMS change, infrastructure, accessibility regression, performance regression, security incident y feature request. Cada clase tiene intake, triage owner, evidence, approval, release, retest y archive.
Patch Decision registra advisory source, affected dependency, exposure assessment por completar, test plan, deploy path, rollback y acceptance. ES-182 no asigna severidad a una vulnerabilidad ficticia ni promete aplicar todas las actualizaciones de inmediato.
Feed Change Procedure versiona schema, mapping, fixtures, consumer list, deprecation, parallel run question, validation, release y rollback. Una API que sigue devolviendo HTTP success puede romper el negocio si cambian campos o estados.
Support Handoff reúne service map, account register, alerts, runbooks, release calendar, known issues, dependency inventory, feed contacts, escalation y access review. Los nombres permanecen vacíos hasta que la inmobiliaria asigne responsables reales.
Technical Archive incluye architecture records, repo history, build records, dependency exports, API contracts, fixtures, migrations, environments, infrastructure decisions, releases, tests, logs schema, monitors, incidents, restores y maintenance history.
Exit Inventory añade source code o límites contractuales, artifacts, configuration schema, secret references sin valores, domain, DNS, cloud, CMS, storage, integrations, accounts, billing, backups, data exports, licenses, tickets y backlog.
Exit Test entrega BUILD-COBRE, API-PIZARRA, FICHA-BASALTO, DEP-CENIZA, RELEASE-UNO, INCIDENTE-PULSO y RESTORE-LINO a otro equipo. El receptor debe explicar dependencias, producir una build ficticia, simular un deploy, localizar un fallo y revocar a la agencia.
El dossier no premia más infraestructura. Premia un sistema explicable, observable y sustituible. Si una función depende de una cuenta privada, un plugin sin export, una persona no nombrada o un paso que nadie puede reconstruir, el criterio permanece pendiente.
Pruebas de idoneidad sectorial que conviene pedir
- Design Handoff aprobado desde ES-181
- Repository, contribution y build contracts
- Dependency inventory y materials export
- API, feed, fixtures y migration evidence
- CMS, forms y privacy implementation map
- Environments, secrets, accounts e infrastructure
- Pipeline, release, rollback y restore
- Performance, accessibility y security evidence
- Logging, monitoring, incidents y runbooks
- Maintenance, archive, revocation y exit
Cómo evaluamos a los proveedores
La comparación abre una página oficial activa y limita cada ficha a capacidades publicadas. No usa premios, testimonials, client logos, performance claims o rankings del propio proveedor. El alcance visible solo determina qué preguntas puede soportar un pilot.
Todos reciben Dossier Sala de Máquinas, fixtures sintéticos, Design Handoff aprobado y los mismos failure states. Primero explican arquitectura y ownership. Después producen evidencia de build, contracts, tests, release y operations. Al final entregan el archivo a un equipo independiente.
Una oferta pasa de página comercial a candidata cuando acepta que cada control puede quedar blocked. El orden no sustituye due diligence, propuesta técnica, contrato, revisión de seguridad, accesibilidad, privacidad, legal, negocio inmobiliario o español nativo.
| Criterio | Peso | Qué se valoró |
|---|---|---|
| Código y entrega | Veinte por ciento | Repository, contribution, build, dependencies, artifacts, configuration, release tags y evidence transferible. |
| Datos e integraciones | Veintidós por ciento | API contracts, MLS o IDX, mappings, fixtures, freshness, migrations, CMS, forms y failure behavior. |
| Infraestructura y despliegue | Dieciocho por ciento | Environments, secrets, accounts, DNS, hosting, pipeline, release, rollback, backup y restore. |
| Calidad y operación segura | Veinte por ciento | Tests, rendimiento, implementación accesible, security controls, logging, monitoring e incident response. |
| Mantenimiento y salida | Veinte por ciento | Patching, feed changes, runbooks, archive, ownership, exports, handover, revocation y exit test. |
Todos los proveedores debían cumplir los mismos requisitos mínimos antes de considerar su posición.
- Página oficial activa con real estate websites, platform, MLS, IDX o integración visible.
- Alcance suficiente para preguntar por implementación, datos, environments y support.
- Capacidad por demostrar para build, deployment, monitoring, restore y maintenance.
- Ownership, exports, documentation, revocation y technical exit pendientes de contrato.
- Sin usar resultados, premios, clientes, reviews o superlativos para asignar posición.
La lista de proveedores investigada
Las posiciones reflejan la metodología publicada y la fecha de corte de las fuentes; no son una garantía de resultados. Cada ficha indica el mejor encaje y la limitación con más probabilidad de cambiar una decisión de compra.
Real Estate Webmasters
Fortalezas documentadas
- Custom websites declaradas.
- MLS integration visible.
- Plataforma inmobiliaria publicada.
- Stack conectado disponible.
Límites por confirmar
- Repo y artifacts no verificados.
- Security operations por probar.
- España y español no confirmados.
- Exit técnico pendiente.
Real Estate Webmasters ocupa la primera posición porque publica custom websites, MLS integration y una plataforma inmobiliaria. Ese alcance encaja de forma directa con API-PIZARRA, FICHA-BASALTO y RELEASE-UNO. La fuente no prueba repositorio, seguridad, rendimiento, España, mantenimiento o salida.
Pida Repository Contract y Architecture Record antes de aceptar el stack. Custom debe identificar qué código, configuración, services y artifacts controla la inmobiliaria, qué retiene el proveedor y qué puede recibir el siguiente equipo.
Ejecute API-PIZARRA y FICHA-BASALTO sobre la integración MLS propuesta. Observe mapping, partial records, withdrawal, cache, jobs, errors, retry, logs y export. ES-177 revisa URLs e indexación; ES-182 acepta conducta técnica.
Congele BUILD-COBRE y RELEASE-UNO. Exija dependency snapshot, tests, environment configuration, deployment evidence, monitoring, rollback y restore. CRM, SEO y PPC ofrecidos por la empresa quedan fuera de ES-182 salvo su technical handoff.
La primera posición refleja proximidad del alcance visible, no una auditoría. Access, secrets, cloud, data region, privacy, WCAG implementation, ASVS controls, logging, support, licenses y complete exit requieren evidencia contractual.
Fuentes sobre los proveedores: Real Estate Webmasters, Real Estate Websites
Union Street Media
Fortalezas documentadas
- Plataforma inmobiliaria visible.
- IDX declarado.
- Listing management publicado.
- Agent y lead management visibles.
Límites por confirmar
- Platform dependency por medir.
- Code access no verificado.
- Data export por demostrar.
- Restore y exit pendientes.
Union Street Media queda segunda por publicar una plataforma inmobiliaria con IDX integration, listing management, lead management y agent management, además de varios modelos de website. El alcance permite una prueba rica de integrations y operations, pero aumenta las preguntas sobre ownership y platform exit.
Modele cada módulo como service en Architecture Record. IDX, listings, agents y leads tienen contracts, data classes, permissions, failures, logs, exports y owners distintos aunque compartan interfaz.
Use FICHA-BASALTO y registros sintéticos de agent y lead sin identidad. Cambie schema, retire listing, bloquee job y cierre access. El proveedor demuestra qué queda en cache, dashboards, exports y backups.
Simule RELEASE-UNO, INCIDENTE-PULSO y RESTORE-LINO dentro de la plataforma. Pida release history, alerting, runbooks, support handoff, data restoration y deprecation process sin conectar production.
La segunda posición reconoce amplitud operacional publicada. Source access, code ownership, dependency inventory, privacy, security, accessibility, performance, restore evidence, licenses y replacement path siguen abiertos.
Fuentes sobre los proveedores: Union Street Media, Real Estate Websites
Luxury Presence
Fortalezas documentadas
- Website personalizada visible.
- Builder publicado.
- IDX conectado a MLS declarado.
- Plataforma integrada.
Límites por confirmar
- Repository no visible.
- Infrastructure ownership abierto.
- Security evidence no probada.
- Technical exit pendiente.
Luxury Presence ocupa la tercera posición por declarar custom-designed website, drag-and-drop builder e IDX connected to MLS. La oferta conecta presentation y data dentro de una plataforma. La fuente no demuestra repository access, deployment model, security operations, backups, maintenance o technical exit.
Reciba los components y estados aprobados por ES-181. Pruebe que el builder conserva markup, validation, permissions, versioning y rollback cuando un editor modifica contenido, sin reabrir la decisión visual.
Ejecute API-PIZARRA con FICHA-BASALTO completa, parcial, retirada y unavailable. Guarde source version, processing state, cache behavior, display version, alert y export. La búsqueda IDX no demuestra freshness por aparecer.
Pida Environment, Account, Release, Logging y Monitoring records. Simule que la agencia pierde access y que una dependency necesita cambio. Otro operator debe reconstruir la situación desde documentation.
La tercera posición reconoce integración pública entre web, plataforma e IDX. Code, infrastructure, secrets, privacy, ASVS scope, Web Vitals evidence, WCAG implementation, restore y exit requieren revisión.
Fuentes sobre los proveedores: Luxury Presence, Real Estate Websites
AgentFire
Fortalezas documentadas
- Website platform publicada.
- Opción fully custom visible.
- Integrations declaradas.
- MLS coverage visible.
Límites por confirmar
- Core versus custom por definir.
- Artifacts no verificados.
- Operations evidence pendiente.
- Exit completo no probado.
AgentFire queda cuarta por publicar una real estate website platform, una opción fully custom, integrations y MLS coverage. Ese alcance permite preguntar por extensiones, feeds y dependency boundaries. La página no prueba code ownership, infrastructure, secure delivery, restore, maintenance o full exit.
Cree Extension Register para addons e integrations. Cada elemento guarda purpose, provider, version, permissions, data, secret reference, webhook, failure, logging, update owner, export y removal test.
Compare configuration y fully custom con el mismo Repository and Build Contract. Una capa personalizada necesita límites claros frente al core de plataforma, además de test, upgrade behavior, support y entrega.
Ejecute DEP-CENIZA y API-PIZARRA sin systems externos. Simule update, integration failure, secret rotation y agency revocation. El provider muestra qué puede observar y qué debe escalar a terceros.
La cuarta posición refleja un scope técnico público útil pero menos específico sobre delivery. MLS mapping, artifacts, environments, infrastructure, security, performance, backup, incident y exit requieren evidencia adicional.
Fuentes sobre los proveedores: AgentFire, Real Estate Website Platform
Agent Image
Fortalezas documentadas
- Fully custom declarado.
- Semi-custom diferenciado.
- Agent Pro visible.
- Opciones IDX publicadas.
Límites por confirmar
- Delivery model por variante abierto.
- Repo y build no verificados.
- Infrastructure no visible.
- Operations y exit pendientes.
Agent Image queda quinta por publicar modelos fully custom, semi-custom y Agent Pro junto con opciones IDX. Las variantes facilitan una Scope Matrix técnica. La fuente no muestra con la misma profundidad repo, build, environments, infrastructure, logging, restore, maintenance o exit.
Compare cada modelo por source access, components, configuration, dependencies, release path, upgrade behavior, integrations, logs, backup, support y export. El nombre comercial no sustituye esos campos.
Ejecute FICHA-BASALTO y API-PIZARRA en la opción IDX. Pruebe partial data, withdrawal, feed failure, cache, error UI y logs. ES-181 conserva presentation decisions; ES-182 conserva implementation evidence.
Simule una actualización de core que rompe una custom layer. El provider registra affected versions, tests, mitigation, release, rollback y maintenance responsibility sin prometer resultado.
La quinta posición refleja un alcance público menos explícito sobre operations. Security controls, accessibility implementation, performance, cloud ownership, restore, incidents, technical archive y revocation quedan abiertos.
Fuentes sobre los proveedores: Agent Image, Real Estate Websites
Compara el flujo de trabajo en tu propio negocio
Revisa los servicios gestionados, los controles de aprobación, los destinos de publicación y los límites visibles de theStacc antes de elegir.
Qué alcance publicado merece pasar al pilot técnico
La tabla resume capacidades que cada proveedor declara sobre sí mismo. Un elemento no visible permanece como pregunta de due diligence y no se convierte en una acusación.
| Proveedor | Modelo de entrega | Alcance documentado | Ideal para | Limitación clave |
|---|---|---|---|---|
| Real Estate Webmasters | Custom web + platform | Custom websites y MLS integration | Código, data y platform boundaries | Repo, operations y exit por probar |
| Union Street Media | Platform + modules | IDX, listings, leads y agents | Integrations y operations | Platform dependency por medir |
| Luxury Presence | Custom web in platform | Builder, custom site e IDX | CMS, frontend y feed | Infrastructure y handover abiertos |
| AgentFire | Platform + custom + integrations | Custom option, addons y MLS coverage | Extensibility | Core versus custom por definir |
| Agent Image | Custom to template models | Custom, semi-custom, Agent Pro e IDX | Elegir delivery model | Operations menos visibles |
Cómo ejecutar un pilot de build, deploy, incidente y relevo
Use BUILD-COBRE, API-PIZARRA, FICHA-BASALTO, SECRETO-NULO, DEP-CENIZA, RELEASE-UNO, INCIDENTE-PULSO y RESTORE-LINO. Ninguno contiene código, endpoint, secret, inmueble, persona, cuenta, sistema o dato real.
Cada paso produce evidence y estados exportables. Un criterio bloqueado conserva su owner y la revisión pendiente. El pilot no toca production ni convierte una simulación en garantía.
1. Reciba el handoff de ES-181
Congele Design Handoff, components, page types, data states, accessibility decisions y rights status aprobados. ES-182 registra cada input y su versión.
Si una constraint técnica exige un cambio, abra request hacia ES-181. No resuelva la diferencia alterando interfaz o copy dentro del código.
- Design version
- Component
- State
- Data
- Accessibility
- Rights
- Constraint
- Acceptance
2. Declare repo, build y dependencies
Complete Repository Contract, Contribution Workflow y Build Record para BUILD-COBRE. Exporte DEP-CENIZA con source, version, use, owner y update path.
Otro environment debe explicar los inputs y producir evidence equivalente. Los secrets permanecen referenciados, nunca copiados.
- Repository
- Revision
- Build
- Artifact
- Dependency
- License
- Test
- Export
3. Pruebe API-PIZARRA
Defina schema, auth reference, pagination, errors, cache, retry, logging y deprecation sin hostname. Use FICHA-BASALTO para complete, partial, withdrawn y unavailable.
Cambie mapping y feed version. Consumers quedan visibles y el rollback conserva evidence. ES-177 revisa SEO; ES-182 acepta conducta técnica.
- Schema
- Mapping
- Version
- Error
- Cache
- Retry
- Consumer
- Withdrawal
4. Separe environments y access
Modele preview, integration, staging y production con data policy, services, accounts, secrets, logs y cleanup. No copie datos reales.
Revogue a la agencia y pierda un backup admin ficticio. El runbook debe recuperar control institucional sin passwords compartidos.
- Environment
- Data rule
- Account
- Role
- Secret ref
- Backup admin
- Recovery
- Revoke
5. Congele RELEASE-UNO
Vincule source revision, build, dependencies, configuration, migrations, contracts, tests, approvals, known issues y rollback target.
Modifique DEP-CENIZA después de una approval. Las pruebas afectadas caducan y la release vuelve al owner responsable.
- Revision
- Build
- Config
- Migration
- Test
- Approval
- Issue
- Rollback
6. Produzca evidencia operativa
Ejecute performance, accessibility implementation, security, browser y integration checks con fixtures. Cada result tiene conditions, version, owner y retest.
Cree logging schema y monitoring signals sin secrets o personal data. Privacidad y seguridad revisan exclusions, access y retention questions.
- Performance
- Accessibility
- Security
- Browser
- Log
- Monitor
- Evidence
- Retest
7. Abra INCIDENTE-PULSO
Simule feed stalled, stale cache y failed job. Registre detection, scope, release, freeze, owner, actions, communication, recovery y review.
El equipo pausa cambios dependientes sin borrar logs. Ninguna pantalla verde sustituye la reconciliación de data y jobs.
- Detect
- Scope
- Freeze
- Owner
- Action
- Communicate
- Recover
- Review
8. Ejecute rollback y RESTORE-LINO
Mueva RELEASE-UNO a un target compatible y compruebe configuration, migration, cache, queue, feed, smoke tests y monitoring.
Restaure un snapshot abstracto en un entorno aislado. Registre access, validation, evidence y gaps sin afirmar RTO o RPO.
- Target
- Compatibility
- Config
- Queue
- Cache
- Restore
- Validate
- Gap
9. Transfiera mantenimiento
Entregue service map, monitors, alerts, runbooks, dependency inventory, feed contracts, release history, incidents, restore evidence y backlog.
El receptor procesa un feed change y un dependency advisory ficticios. Cada decision conserva test, approval, release y rollback.
- Service map
- Alert
- Runbook
- Dependency
- Feed
- Release
- Incident
- Backlog
10. Complete el technical exit
Exporte repo o límites, artifacts, configurations, contracts, fixtures, data, accounts, billing, backups, logs, licenses, tickets y decisions.
Otro equipo produce BUILD-COBRE, explica INCIDENTE-PULSO, valida RESTORE-LINO y revoca agency users y integrations. La memoria oral no pasa.
- Source
- Artifact
- Config
- Contract
- Account
- Backup
- Revoke
- Receipt
Errores que hacen inútil una comparativa SEO
- Aceptar código que solo compila en un portátil. Documente inputs, versions, dependencies, configuration, artifacts y tests. Otra environment necesita evidence equivalente.
- Llamar integración a una pantalla con datos. Exija contract, mapping, versions, errors, cache, retry, freshness, logs, withdrawal y export.
- Guardar secrets en repo o tickets. Use references, roles, rotation y revocation. El dossier no contiene valores, passwords, tokens o private keys.
- Compartir admin entre agencia y cliente. Cada user necesita identity, purpose, role, approval, review, expiry, recovery y revocation documentados.
- Desplegar desde una rama sin manifest. Una release enlaza revision, build, dependencies, config, migrations, tests, approvals, issues y rollback target.
- Confundir status HTTP con éxito de negocio. Un feed puede responder y traer schema o state incorrectos. Valide contract, data y downstream behavior.
- Medir performance una sola vez. Guarde page type, fixture, device, network, tool, conditions, result distribution question, budget y regression evidence.
- Registrar requests completos. Defina eventos y fields necesarios, data exclusions, access, protection, monitoring y retention con security y privacy review.
- Tener backup sin restore test. Pruebe acceso, compatibilidad, environment aislado, validation, evidence y gaps. Un indicador de panel no basta.
- Entregar un ZIP sin operación. El exit incluye repo, artifacts, config, accounts, data, backups, runbooks, incidents, licenses, tickets, revocation y receipt.
Preguntas frecuentes
Pida repositorio o límites contractuales, build records, artifacts, dependency export, API y feed contracts, fixtures, migrations, configuration schema, environments, accounts, releases, tests, logs, monitors, backups, restore evidence, runbooks, incidents, maintenance history y backlog. Cada elemento necesita versión, owner, approval, evidence, export y revocation path.
Su página oficial publica custom websites, MLS integration y una plataforma inmobiliaria. Ese alcance es el más cercano al pilot de código, feed y platform boundaries. La posición no confirma calidad, España, repositorio, infraestructura, privacidad, accesibilidad, seguridad, rendimiento, soporte, mantenimiento, restauración, exportabilidad ni resultados.
ES-181 posee research, arquitectura de información, wireframes, interfaz, sistema de diseño, accesibilidad de diseño y derechos. ES-182 recibe versiones aprobadas e implementa código, feeds, infrastructure, deployment, tests y operations. Una restricción técnica vuelve a ES-181 mediante change request; el developer no rediseña en silencio.
Use fixtures sintéticos para records complete, partial, withdrawn, duplicate, delayed, malformed y unavailable. Registre schema, mapping, identifier, versions, authentication reference, cache, retries, freshness, logs y consumer behavior. No conecte production. ES-177 revisa URLs e indexación; ES-182 acepta processing y failure states.
El contrato debe nombrar organization owner, backup admins, agency users, billing, recovery, export y revocation para repo, cloud, registrar, DNS, CDN, CMS y monitoring. La estructura concreta requiere revisión técnica y jurídica. El comprador necesita recuperar operación sin una cuenta personal o un password compartido.
Congele source revision, build ID, artifact, dependency snapshot, configuration schema, migration, contract versions, test results, approvals, known issues, monitoring plan, support owner y rollback target. Un cambio posterior invalida evidence afectada. El release manifest debe permitir que otra persona reconstruya exactamente qué se propuso desplegar.
Seleccione requisitos con especialistas y vincule cada control a component, threat, environment, test, evidence, defect, owner y retest. Añada dependency, secret, access, logging, monitoring, incident y patch records. OWASP ASVS y NIST SSDF orientan preguntas; una checklist, un scan o una herramienta aislada no garantiza seguridad.
Registre page type, fixture, device, network, browser, tool, run conditions, LCP, INP, CLS, server timing cuando aplique, result distribution question, budget, regression, release y owner. Google Web Vitals define métricas útiles, pero los thresholds contractuales y la interpretación requieren contexto y revisión técnica.
Defina eventos, fields, data exclusions, severity proposal, correlation, collection, access, protection, retention question, monitors, receivers y runbooks. No registre secrets o payloads completos por defecto. OWASP ofrece una guía de logging; seguridad y privacidad deben adaptar el alcance a la aplicación y la jurisdicción.
Rollback cambia una release por una versión compatible anterior y valida code, configuration, migrations, cache, queues, feed y smoke tests. Restore recupera datos o configuración desde backup en un entorno controlado. Ambos necesitan autoridad, steps, evidence, validation y gaps; ninguno queda probado porque exista un botón en el panel.
Separe defects, dependencies, vulnerabilities, feed changes, CMS changes, infrastructure, accessibility regressions, performance regressions, incidents y features. Cada clase necesita intake, triage owner, evidence, approval, test, release, rollback y archive. Añada account review, secret rotation, backup restore y documentation updates con responsables nombrados.
Entregue source o límites, artifacts, configuration schema, contracts, fixtures, migrations, dependencies, accounts, billing, data exports, backups, logs, monitors, runbooks, releases, incidents, licenses, tickets y backlog. El receptor debe construir, desplegar, restaurar y revocar en laboratorio sin depender de dashboards privados o memoria oral.
Fuentes y política editorial
Consulta las fuentes enlazadas junto con la metodología y el aviso del editor de este artículo. Confirma los precios, las funciones y las condiciones actuales con cada proveedor; una cita por sí sola no demuestra que se haya probado el producto.
- [01]Real Estate Webmasters, Real Estate Websites
- [02]Union Street Media, Real Estate Websites
- [03]Luxury Presence, Real Estate Websites
- [04]AgentFire, Real Estate Website Platform
- [05]Agent Image, Real Estate Websites
- [06]OWASP, Application Security Verification Standard
- [07]OWASP, Logging Cheat Sheet
- [08]NIST, Secure Software Development Framework 1.1
- [09]Google web.dev, Web Vitals
- [10]W3C, Web Content Accessibility Guidelines 2.2
- [11]AEPD, Guía de privacidad desde el diseño
- [12]RFC Editor, RFC 9110 HTTP Semantics
Compre el sistema que puede sobrevivir a su propio proveedor
Reciba una versión aprobada de ES-181 y conviértala en contracts, code, builds y tests visibles. Mantenga repo, cloud, domain, accounts y backups bajo ownership documentado. Pruebe feed failure, release, rollback, logging, incident y restore antes de production. Entregue dependency history, runbooks, monitors y maintenance backlog antes del relevo. La compra termina cuando otro equipo puede construir, desplegar, observar, recuperar y revocar sin credentials compartidas, dashboards privados o memoria oral.