{ "componentChunkName": "component---src-pages-publicaciones-index-js", "path": "/publicaciones/", "result": {"data":{"allMarkdownRemark":{"edges":[{"node":{"frontmatter":{"title":"Web a medida, WordPress o No-Code: cuál elegir en 2026","description":"La decisión que más dinero ahorra (o cuesta) a un negocio. Un marco de 3 preguntas, ventajas reales y ejemplos para elegir sin equivocarte.","slug":"/publicaciones/web-a-medida-vs-wordpress-vs-no-code","date":"2026-09-11T00:00:00.000Z","tags":["Desarrollo Web","Estrategia","Negocios"],"draft":false},"html":"
\n \n
▶  Vídeo en YouTube · próximamente
\n
\n

Cada semana hablo con negocios que pagaron por la web equivocada. No porque la tecnología fuera mala —WordPress, No-Code y el desarrollo a medida son todos buenos—, sino porque eligieron la herramienta antes de entender el problema que debía resolver.

\n

En esta guía te doy el mismo marco que uso como consultor para decidir entre las tres opciones, con ejemplos reales y las tres preguntas que casi siempre resuelven la duda.

\n

El error de empezar por la herramienta

\n

La pregunta no es \"¿qué tecnología uso?\". Es \"¿qué papel juega esta web en mi negocio?\".

\n

Hay un eje que lo ordena casi todo: presencia ↔ producto. En un extremo, una web que es un folleto digital: informa y da confianza. En el otro, una web que es el negocio: por ahí entran los ingresos, se operan procesos y se integran herramientas. Dónde caigas en ese eje decide la tecnología, no al revés.

\n

WordPress: cuándo sí, cuándo no

\n

Cuándo sí: webs de presencia, blogs, catálogos, proyectos con presupuesto ajustado y cuando quieres autonomía para editar el contenido tú mismo. Es maduro, económico y hay talento de sobra.

\n

Cuándo no: cuando necesitas lógica de negocio compleja, mucho tráfico, integraciones a medida o rendimiento crítico. El error clásico: llenarlo de plugins hasta que se vuelve lento e inseguro.

\n

No-Code: rápido, con techo

\n

Herramientas como Webflow, Framer o Bubble.

\n

Cuándo sí: para validar una idea o lanzar un MVP rápido, o para una landing potente sin equipo técnico. Llegas al mercado en días, no meses.

\n

Cuándo no: cuando escalas. Los límites de la plataforma y sus costes crecientes te acaban atrapando (el famoso vendor lock-in). No-code no es \"de juguete\", pero tiene techo.

\n

Desarrollo a medida: cuando el software es el negocio

\n

Cuándo sí: cuando tu negocio depende del producto y necesitas velocidad, escala e integraciones —con tu ERP, tu CRM, pasarelas de pago o una experiencia única que ninguna plantilla te da.

\n

Cuándo no: si solo necesitas presencia. Ahí, pagar por desarrollo a medida es tirar dinero.

\n

Un caso real: un negocio gestionaba el alquiler de equipo con una libreta y llamadas. Hoy tiene una plataforma con configurador de packs, pago con Stripe y gestión de entregas. Ahí sí tocaba a medida —pero no un día antes.

\n

El marco de 3 preguntas

\n

Antes de invertir un euro, respóndete:

\n
    \n
  1. ¿Tu web es un folleto o una máquina de ventas/operación?
    2. \n
  2. ¿Cuánto te cuesta —en dinero real— que falle o vaya lenta?
    3. \n
  3. ¿Necesita integrarse con otras herramientas o crecer mucho?
    4. \n
\n

Si las tres apuntan a \"folleto, poco coste, sin integraciones\", WordPress o No-Code te sobran. Si apuntan a \"máquina, coste alto, integraciones y escala\", es a medida.

\n

Conclusión

\n

No hay una tecnología \"mejor\": hay una adecuada para el papel que tu web juega en tu negocio. Elige el problema primero; la herramienta es la consecuencia.

\n

Si tienes esa decisión encima de la mesa y no quieres adivinar, agenda una consulta de 30 minutos y lo vemos con tu caso concreto.

"}},{"node":{"frontmatter":{"title":"Tarjetas clicables y accesibles","description":"Tarjetas clicables con varios enlaces internos","slug":"/publicaciones/clickable-cards","date":"2021-04-21T00:00:00.000Z","tags":["Accesibilidad","CSS"],"draft":false},"html":"

Demo en Codepen

\n

Disposición de tarjeta donde la tarjeta en sí no es un enlace, pero toda la tarjeta es clicable (mediante un pseudo-elemento :before sobre el <a> principal). Los enlaces dentro de la tarjeta siguen siendo clicables.

\n

CSS

\n
.grid__item {\n  &:hover,\n  &:focus-within {\n    background-color: #eee;\n  }\n\n  a {\n    position: relative;\n    z-index: 1;\n  }\n\n  h2 {\n    a {\n      position: static;\n\n      &:hover,\n      &:focus {\n        color: blue;\n      }\n\n      &:before {\n        content: '';\n        display: block;\n        position: absolute;\n        z-index: 0;\n        width: 100%;\n        height: 100%;\n        top: 0;\n        left: 0;\n        transition: background-color 0.1s ease-out;\n        background-color: transparent;\n      }\n    }\n  }\n}
"}},{"node":{"frontmatter":{"title":"Modo oscuro sin parpadeo","description":"Cómo implementar modo oscuro sin el parpadeo del tema por defecto","slug":"/publicaciones/dark-mode-toggle","date":"2021-04-21T00:00:00.000Z","tags":["Temas","Modo Oscuro"],"draft":false},"html":"

Botón de modo oscuro sin el parpadeo del tema por defecto. Las claves:

\n\n

HTML

\n
<!DOCTYPE html>\n<html lang=\"es\" data-theme=\"light\">\n  <head>\n    <meta charset=\"utf-8\" />\n    <meta name=\"viewport\" content=\"width=device-width, initial-scale=1.0\" />\n    ...\n    <script>\n      // Si hay un tema guardado en localStorage, aplícalo al <html>\n      const localStorageTheme = localStorage.getItem('theme');\n      if (localStorageTheme) {\n        document.documentElement.setAttribute('data-theme', localStorageTheme);\n      }\n    </script>\n  </head>\n  <body>\n    <div class=\"theme-toggle\">\n      <button\n        class=\"theme-toggle-btn js-theme-toggle\"\n        aria-label=\"Activar modo oscuro\"\n        title=\"Activar modo oscuro\"\n      >\n        <!--\n        <svg class=\"light-mode\">\n          <use xlink:href=\"#sun\"></use>\n        </svg>\n        <svg class=\"dark-mode\">\n          <use xlink:href=\"#moon\"></use>\n        </svg>\n        -->\n      </button>\n    </div>\n\n    <script src=\"app.js\"></script>\n  </body>\n</html>
\n

Variables CSS

\n
:root {\n  --bg: #ffffff;\n  --text: #000000;\n}\n\n[data-theme='dark'] {\n  --bg: #000000;\n  --text: #ffffff;\n}
\n

JavaScript

\n
app.js
\n
const themeToggleBtn = document.querySelector('.js-theme-toggle');\n\nthemeToggleBtn.addEventListener('click', () => onToggleClick());\n\nconst onToggleClick = () => {\n  const { theme } = document.documentElement.dataset;\n  const themeTo = theme && theme === 'light' ? 'dark' : 'light';\n  const label = `Activar modo ${themeTo === 'dark' ? 'claro' : 'oscuro'}`;\n\n  document.documentElement.setAttribute('data-theme', themeTo);\n  localStorage.setItem('theme', themeTo);\n\n  themeToggleBtn.setAttribute('aria-label', label);\n  themeToggleBtn.setAttribute('title', label);\n};
\n

Recursos

\n"}},{"node":{"frontmatter":{"title":"Error de Docker Compose","description":"Discrepancias de versión en docker-compose","slug":"/publicaciones/docker-error","date":"2019-12-13","tags":["WordPress","Docker"],"draft":false},"html":"

Problema

\n

Hace poco, mientras actualizaba Skela con webpack, me encontré con un error raro: no podía ejecutar un script sencillo:

\n
bin/composer
\n
#!/bin/bash\ndocker-compose exec -w /var/www/html/wp-content/themes/skela wordpress composer \"$@\"
\n

Al intentar ejecutar este script con ./bin/composer install, obtenía este error en la terminal:

\n
ERROR: Setting workdir for exec is not supported in API < 1.35 (1.30)
\n

El error venía de la opción -w del comando docker-compose exec dentro del script composer.

\n

Solución

\n

La solución fue actualizar la versión en mi archivo docker-compose.yml, de la 3.5 a la 3.6. Es curioso, porque la 3.5 no se parece en nada a la versión de API 1.35 del mensaje de error 🤷

\n
docker-compose.yml
\n
version: '3.6'services:\n  wordpress:\n    build:
"}},{"node":{"frontmatter":{"title":"Error al publicar en WordPress","description":"Intentando crear un post sencillo en WordPress","slug":"/publicaciones/wordpress-publish-error","date":"2019-12-03T00:00:00.000Z","tags":["WordPress"],"draft":false},"html":"

Problema

\n

Hace poco, trabajando en un proyecto de WordPress con Ups Dock, me encontré con un error raro: no podía actualizar ni publicar un post sencillo en mi panel de WordPress local.

\n

Se veía más o menos así:

\n

\n \n \n \n \n

\n

A veces el mensaje de error era algo más útil: Publishing failed. Error message: The response is not a valid JSON response.

\n

\n \n \n \n \n

\n

Y al abrir la consola, veía estos errores:

\n

\n \n \n \n \n

\n

Solución

\n

Como el mensaje de error hablaba de una respuesta JSON, al principio pensé que era un problema de Gutenberg o de ACF. Pero resultó que ocurría porque estaba usando el panel de WordPress por https (es decir, https://project.ups.dock/wp-admin), y no el panel sin cifrar (http://project.ups.dock/wp-admin).

\n

¡Era un error de CORS! Estaba intentando modificar un dominio sin https desde un dominio con https. Cambiar al panel de WordPress sin https me permitió publicar posts sin problema.

"}}]}},"pageContext":{}}, "staticQueryHashes": ["1866466693","1994492073","2009693873","2031412112","3825832676"]}