![\"\"](\"/_next/image?url=%2Fcms%2Fblog%2Fmaximizando-la-flexibilidad-y-rendimiento-web-las-ventajas-de-combinar-headless-cms-con-nextjs-y-astro%2Fankle-band3.jpg&w=3840&q=75\"/)
Hay temas que parecen puramente técnicos hasta que los bajas a una decisión real de proyecto. Ahí es donde se vuelven interesantes.
\nDurante años pensé en webs, CMS, automatización y producto como piezas separadas. Ahora las veo más conectadas. Una web explica. Un CMS mantiene viva la información. Una automatización continúa la conversación. Un producto ordena operaciones.
\nCuando esas capas se diseñan juntas, el resultado se siente menos improvisado.
\nNo me interesa usar la tecnología más grande por defecto. Me interesa elegir lo que deja el proyecto más claro. A veces eso es Astro. A veces Next.js. A veces Payload. A veces WordPress. A veces Salesforce Marketing Cloud.
\nLa tecnología cambia. El criterio se acumula.
\nCada vez me importa más construir cosas útiles, mantenibles y con intención visual. No solo webs bonitas. Sistemas que expliquen, conviertan, editen, automaticen o ayuden a trabajar.
\nBo Labs va justo por ahí: diseño cuidado, código serio y menos ruido alrededor.
\nAl final, casi todo vuelve a lo mismo: construir con intención, quitar ruido y dejar una base que alguien pueda usar, entender y mantener.
", "url": "https://www.bo-labs.com/blog/lo-que-ahora-entiendo-sobre-webs-cms-automatizacion-y-producto", "title": "Lo que ahora entiendo sobre webs, CMS, automatización y producto", "summary": "Una síntesis de cómo conecto diseño, desarrollo, CMS, operaciones y automatización después de varios proyectos muy distintos.", "date_modified": "2026-05-15T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/dashboards-internos-claridad-antes-que-decoracion", "content_html": "Hay temas que parecen puramente técnicos hasta que los bajas a una decisión real de proyecto. Ahí es donde se vuelven interesantes.
\nEs fácil diseñar un dashboard que se vea espectacular en Dribbble. Mucho más difícil es diseñar uno que alguien use ocho horas sin cansarse.
\nLas herramientas internas tienen otra lógica. La belleza está en la densidad bien ordenada, en los estados claros y en que las acciones importantes no se escondan.
\nUn dashboard interno se usa muchas veces. Por eso los patrones importan más que la sorpresa. Filtros previsibles, tablas legibles, confirmaciones claras, errores útiles y exportaciones donde toca.
\nLa interfaz tiene que volverse familiar sin volverse torpe.
\nMe gusta pensar en estos productos como diseño silencioso. Si funciona, el usuario no piensa en la interfaz. Piensa en su trabajo.
\nEso no es falta de diseño. Es diseño bien educado.
\nAl final, casi todo vuelve a lo mismo: construir con intención, quitar ruido y dejar una base que alguien pueda usar, entender y mantener.
", "url": "https://www.bo-labs.com/blog/dashboards-internos-claridad-antes-que-decoracion", "title": "Dashboards internos: claridad antes que decoración", "summary": "Un dashboard serio no necesita impresionar en una captura. Necesita ayudar a trabajar mejor, más rápido y con menos errores.", "date_modified": "2026-03-18T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/drivers-management-convertir-operaciones-complejas-en-producto-usable", "content_html": "Hay dashboards que muestran información. Y hay herramientas internas que sostienen una operación. Drivers Management pertenece a la segunda categoría.
\nCuando una aplicación tiene que gestionar conductores, turnos, calendarios, cuadrantes, informes, compensaciones, vacaciones, auditoría, empresas y reglas laborales, la interfaz deja de ser una capa decorativa. Se convierte en una forma de reducir errores.
\nLa tentación con un dashboard interno es empezar por componentes: tablas, filtros, cards, modales. Todo eso hace falta, pero no resuelve el problema por sí solo.
\nEl trabajo real empieza al entender qué está intentando hacer la persona usuaria. Buscar un conductor. Cambiar una empresa. Crear un turno. Revisar horas. Cerrar un periodo. Exportar datos para nómina. Ver si una compensación está pendiente. Corregir vacaciones. Cada acción tiene consecuencias.
\nPor eso una herramienta de operación necesita conocer el dominio. No basta con "CRUD de conductores". Hay PACTO, variables automáticas, festivos, jornadas, partes entregados, horas efectivas, excesos, históricos y periodos archivados.
\nEn proyectos así, las reglas son más importantes que las pantallas. Una empresa cambia y eso afecta variables. Un periodo archivado no debería tocarse. Un número de turno duplicado puede provocar errores. Una búsqueda que no entiende acentos ralentiza el trabajo diario.
\nMuchas de estas cosas parecen pequeñas hasta que se repiten cientos de veces. Ahí una mejora de UX deja de ser estética y se vuelve ahorro real.
\nPor ejemplo: ordenar resultados por relevancia, sugerir el siguiente número de turno disponible, mostrar números ya usados, paginar días con muchos turnos o validar antes de guardar. Son detalles poco llamativos, pero cambian la confianza de la herramienta.
\nLa parte de reporting también tiene mucha profundidad. No se trata solo de mostrar un gráfico. Se trata de convertir datos diarios en lectura administrativa: horas, presencia, efectivos, excesos, variables, PACTO, fijos mensuales, CP+QM, festivos, compensaciones y exportaciones.
\nEl sistema tiene que permitir filtrar, bloquear vistas, archivar periodos y reabrirlos cuando toca. Esa trazabilidad es clave porque los datos no viven solo en pantalla. Terminan en Excel, PDF, nómina, conversaciones internas y decisiones.
\nUna exportación mal planteada puede convertir una buena app en una fuente de trabajo manual. Una exportación bien pensada ahorra horas.
\nMe gustan este tipo de productos porque no permiten mucho teatro visual. Si decoras de más, molestas. Si escondes una acción importante, generas errores. Si no confirmas una operación destructiva, das miedo.
\nEl diseño tiene que ser tranquilo, denso cuando hace falta y muy claro en estados: guardado, error, sin cambios, sincronizando, archivado, pendiente, resuelto.
\nTambién tiene que reconocer que la persona que lo usa quizá lo abre todos los días. No necesita sorpresa. Necesita confianza.
\nDrivers Management me recuerda que una interfaz interna puede tener mucho diseño aunque no parezca espectacular. El diseño está en el orden, en las reglas, en los mensajes, en los filtros y en evitar que alguien cometa un error caro.
\nCuando un producto operativo ahorra tiempo y reduce incertidumbre, ya está haciendo su trabajo.
", "url": "https://www.bo-labs.com/blog/drivers-management-convertir-operaciones-complejas-en-producto-usable", "title": "Drivers Management: convertir operaciones complejas en producto usable", "summary": "Lo que cambia cuando un dashboard interno tiene que sostener turnos, conductores, informes, vacaciones, compensaciones y reglas reales.", "date_modified": "2026-02-11T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/ok-flows-formularios-journeys-y-salesforce-con-mas-intencion", "content_html": "Hay formularios que solo recogen datos. Y luego están los formularios que forman parte de una campaña, de un journey, de una experiencia de cliente y de una operación de marketing real. La diferencia parece pequeña desde fuera, pero cambia todo por dentro.
\nOK Flows nace de esa segunda idea. No como un formulario bonito con campos arrastrables, sino como una capa de interacción para equipos que trabajan con Salesforce Marketing Cloud, audiencias, Data Extensions, CloudPages, prefill, respuestas parciales y lógica de campaña.
\nCuando un formulario vive dentro de una campaña, deja de ser una página aislada. Tiene que saber de dónde viene la persona, qué datos ya existen, qué se puede mostrar, qué se debe ocultar y qué ocurre después de enviar.
\nAhí es donde un builder plano se queda corto. No basta con añadir un input de email, un dropdown y un botón. Necesitas un editor que permita construir una experiencia, probarla, publicarla y conectarla con datos reales sin que cada campaña sea una pieza nueva hecha a mano.
\nPor eso me interesa pensar en OK Flows como producto. Tiene una superficie de marketing, autenticación, dashboard, builder, runtime público y operación interna. Cada capa tiene su función. El editor no es lo mismo que el player. La lógica no es lo mismo que la integración. El diseño visual no es lo mismo que la entrega de datos.
\nLa parte más visible es el builder: canvas, inspector, preview, block library, edición inline, opciones, CTAs, theme y publicación. Pero lo interesante está en cómo eso se conecta con lo que ocurre debajo.
\nUn formulario serio necesita bloques simples y bloques complejos. Campos de texto, email o teléfono, sí. Pero también hidden fields, hidden JSON, calculated fields, file upload, ranges, address, contact, availability, allocations o semantic differential cuando la campaña lo pide.
\nTambién necesita lógica. No solo "si respuesta A entonces muestra B", sino capacidad para simular, auditar condiciones, entender visibilidad y evitar publicar journeys rotos. En marketing automation, una condición mal planteada no es un detalle técnico: puede afectar a una audiencia completa.
\nUna de las partes más delicadas es la personalización. Es muy tentador meter datos en una URL y seguir. Pero si hay PII o información sensible, eso se vuelve peligroso rápido.
\nPor eso la idea de prefill seguro es clave. Tokens opacos, JWT, expiración, reglas de acceso, resolución server-side y control de qué se expone al runtime. El usuario siente que la experiencia viene preparada para él, pero la campaña no va dejando datos innecesarios por el camino.
\nEsto es justo el tipo de detalle que diferencia una demo de un sistema. La demo enseña campos precargados. El sistema piensa en seguridad, caducidad, auditoría y operación.
\nConectar con SFMC tampoco es solo "enviar una respuesta". Hay Data Extensions, mappings, CloudPages, logs de entrega, payload snapshots, estados delivered/failed y, en algunos casos, audience prefill runs que preparan URLs personalizadas para campañas grandes.
\nEse flujo necesita ser visible para quien opera. Si algo falla, no puede quedar escondido en una consola. Hace falta saber qué se envió, cuándo, con qué mapping y hacia dónde.
\nLa integración buena no desaparece porque sea simple. Desaparece porque está bien diseñada.
\nOtro punto fuerte es aceptar que la gente abandona. En vez de tratarlo como fracaso invisible, el sistema puede capturar progreso parcial, entender dónde se pierde una persona y permitir recuperación sin romper la experiencia.
\nEso abre puertas interesantes para campañas largas, formularios con varios pasos o experiencias donde cada respuesta tiene valor aunque no haya submit final.
\nLa lección de OK Flows es sencilla: un formulario puede ser infraestructura. Puede conectar marca, datos, automatización, UX y operación. Pero para que eso funcione hay que diseñarlo como producto, no como una lista de campos.
\nAhí es donde me interesa trabajar: en piezas que parecen simples por fuera, pero que por dentro tienen criterio, orden y una razón clara para existir.
", "url": "https://www.bo-labs.com/blog/ok-flows-formularios-journeys-y-salesforce-con-mas-intencion", "title": "OK Flows: formularios, journeys y Salesforce con más intención", "summary": "Por qué un formulario puede ser mucho más que campos: lógica, personalización, prefill, respuestas parciales y conexión con campañas.", "date_modified": "2026-01-14T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/cloudpages-formularios-y-data-extensions-sin-caos", "content_html": "Hay temas que parecen puramente técnicos hasta que los bajas a una decisión real de proyecto. Ahí es donde se vuelven interesantes.
\nUna CloudPage puede parecer una landing sencilla, pero debajo suele haber datos, validaciones, formularios, audiencias, estados y expectativas de campaña.
\nSi solo se diseña la pantalla, falta la mitad del trabajo.
\nEl formulario debe guardar lo que toca, con nombres claros y estructura preparada para que el equipo pueda usar esa información después.
\nUna Data Extension mal pensada se convierte rápido en deuda. Campos ambiguos, duplicados o sin relación con el journey hacen que todo sea más frágil.
\nLa persona que rellena el formulario necesita claridad. El equipo necesita datos limpios. La campaña necesita continuidad.
\nCuando esas tres cosas encajan, una CloudPage deja de ser una página suelta y se vuelve una pieza seria del sistema.
\nAl final, casi todo vuelve a lo mismo: construir con intención, quitar ruido y dejar una base que alguien pueda usar, entender y mantener.
", "url": "https://www.bo-labs.com/blog/cloudpages-formularios-y-data-extensions-sin-caos", "title": "CloudPages, formularios y Data Extensions sin caos", "summary": "Cómo pensar una landing de SFMC para que la experiencia visible y los datos internos no se peleen.", "date_modified": "2025-12-17T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/emails-html-el-front-end-mas-raro-que-todavia-importa", "content_html": "Hay temas que parecen puramente técnicos hasta que los bajas a una decisión real de proyecto. Ahí es donde se vuelven interesantes.
\nSi vienes del front-end moderno, HTML email se siente como viajar en el tiempo. Tablas, estilos inline, soporte irregular, clientes caprichosos y muchas cosas que en web normal darías por hechas.
\nPero sigue importando. Muchísimo. Un email mal renderizado puede arruinar una campaña muy trabajada.
\nLa gracia está en aceptar el medio. No puedes depender de CSS moderno como en una app. Tienes que construir con fallbacks, probar más y pensar en clientes que interpretan el código de formas distintas.
\nEso obliga a ser más disciplinado: estructura simple, imágenes cuidadas, textos claros y QA real.
\nUn email parece una pieza pequeña, pero toca marca, datos, segmentación, conversión y confianza.
\nPor eso me gusta tratarlo como front-end serio, aunque sea el front-end más raro de todos.
\nAl final, casi todo vuelve a lo mismo: construir con intención, quitar ruido y dejar una base que alguien pueda usar, entender y mantener.
", "url": "https://www.bo-labs.com/blog/emails-html-el-front-end-mas-raro-que-todavia-importa", "title": "Emails HTML: el front-end más raro que todavía importa", "summary": "Maquetar emails sigue siendo extraño, limitado y necesario. Y justo por eso requiere mucho cuidado.", "date_modified": "2025-11-19T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/salesforce-marketing-cloud-desde-el-lado-tecnico", "content_html": "Salesforce Marketing Cloud puede parecer, desde fuera, una plataforma para enviar emails. Pero cuando trabajas dentro, entiendes rápido que la parte de envío es solo una pieza.
\nSFMC mezcla datos, audiencias, journeys, CloudPages, Data Extensions, AMPscript, SSJS, HTML email, QA y operación. Y cuando una campaña sale a varios mercados, idiomas o segmentos, cada pequeño detalle cuenta.
\nUna campaña no es un HTML suelto. Tiene assets, audiencias, reglas, fechas, variantes, enlaces, imágenes, textos legales, datos de personalización y puntos de seguimiento.
\nSi una parte falla, el resultado puede verse afectado aunque el diseño sea bueno. Un campo mal nombrado en una Data Extension, una audiencia importada con una columna incorrecta, una condición mal escrita en AMPscript o una imagen que no carga en cierto cliente de correo pueden romper la experiencia.
\nPor eso SFMC exige una mezcla rara de capacidades: front-end, datos, orden, paciencia y mentalidad de QA.
\nEl email HTML es probablemente el front-end más extraño que sigue siendo crítico. Muchas reglas modernas no aplican. Hay que pensar en tablas, estilos inline, clientes con soporte irregular y fallbacks.
\nEso cambia la forma de trabajar. No puedes confiar solo en que "en mi navegador se ve bien". Hay que revisar render, mobile, desktop, dark mode si aplica, pesos de imagen, enlaces, tracking y consistencia con la marca.
\nEs un trabajo menos glamuroso que una landing moderna, pero en términos de negocio puede ser igual o más importante.
\nLas CloudPages conectan la parte visible con la operación. Una landing puede capturar datos, mostrar contenido personalizado, validar respuestas y enviar información a una Data Extension.
\nPero para que eso funcione bien, hay que pensar en estructura. Qué campos se guardan, cómo se nombran, qué pasa si falta un dato, cómo se relaciona con el journey, qué verá el usuario después y qué necesita revisar el equipo.
\nUna CloudPage sencilla por fuera puede tener bastante lógica por dentro.
\nAMPscript suele aparecer cuando necesitas personalización, condiciones, lectura o escritura de datos. SSJS puede ayudar cuando la lógica se vuelve más compleja. Ninguno debería usarse como una bolsa de trucos.
\nMe gusta separar mentalmente markup, datos y reglas. Si todo está mezclado, mantener una campaña se vuelve doloroso. Si hay orden, la pieza puede evolucionar, duplicarse para otro mercado o ajustarse sin miedo.
\nEn marketing automation, QA no es una fase decorativa. Es parte del desarrollo. Revisar enlaces, imágenes, variantes, textos, audiencias, datos y comportamiento no es opcional.
\nEl usuario no ve el esfuerzo. Solo ve si el email llega bien, si la landing carga, si el formulario funciona y si la experiencia tiene sentido.
\nSFMC me interesa porque obliga a conectar tecnología con operación real. No basta con construir algo bonito. Tiene que enviarse bien, guardar datos bien, integrarse bien y poder ser usado por equipos que van rápido.
\nCuando eso ocurre, marketing automation deja de ser una caja complicada y se convierte en una infraestructura que sostiene campañas con más confianza.
", "url": "https://www.bo-labs.com/blog/salesforce-marketing-cloud-desde-el-lado-tecnico", "title": "Salesforce Marketing Cloud desde el lado técnico", "summary": "SFMC no es solo enviar emails: es datos, audiencias, CloudPages, AMPscript, journeys, QA y operación.", "date_modified": "2025-10-22T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/marketing-automation-la-web-no-acaba-en-el-clic", "content_html": "Hay temas que parecen puramente técnicos hasta que los bajas a una decisión real de proyecto. Ahí es donde se vuelven interesantes.
\nMuchas webs se obsesionan con el botón. “Contacta”, “descarga”, “regístrate”. Pero la pregunta importante viene después: ¿qué pasa cuando alguien hace clic?
\nAhí empieza el terreno de marketing automation. Formularios, CRM, emails, journeys, segmentación, datos y seguimiento.
\nUna landing no debería vivir aislada. Si capta un lead, ese dato tiene que llegar bien a algún sitio. Si promete una respuesta, el sistema debe sostenerla. Si personaliza una experiencia, la fuente de datos debe ser fiable.
\nLa web se vuelve más útil cuando conecta con lo que ocurre después.
\nPara mí, esto une dos mundos: la experiencia visible y la operación invisible. El usuario siente claridad. El equipo recibe datos ordenados.
\nAhí una web deja de ser una página y empieza a ser infraestructura comercial.
\nAl final, casi todo vuelve a lo mismo: construir con intención, quitar ruido y dejar una base que alguien pueda usar, entender y mantener.
", "url": "https://www.bo-labs.com/blog/marketing-automation-la-web-no-acaba-en-el-clic", "title": "Marketing automation: la web no acaba en el clic", "summary": "Una web puede ser el inicio de un sistema: captación, formularios, CRM, emails, journeys y seguimiento.", "date_modified": "2025-09-24T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/de-pagina-bonita-a-sistema-mantenible", "content_html": "Hay temas que parecen puramente técnicos hasta que los bajas a una decisión real de proyecto. Ahí es donde se vuelven interesantes.
\nUna página puede verse muy bien el día de entrega y aun así ser difícil de mantener. Pasa cuando todo está hecho a medida sin patrón, cuando cada sección inventa sus reglas y cuando tocar un texto rompe el layout.
\nLa web real empieza el día dos, cuando hay que cambiar algo.
\nUn sistema mantenible no tiene por qué ser enorme. Puede ser simplemente una colección clara de componentes, estilos consistentes, tokens básicos y reglas para contenido variable.
\nLos límites ayudan. Si un botón tiene tres variantes, se usa con criterio. Si tiene veinte, nadie sabe cuál toca.
\nLa buena interfaz no es solo la que se ve bien en una captura. Es la que sigue funcionando cuando cambian textos, imágenes, idiomas y necesidades.
\nEso es craft menos visible, pero más importante.
\nAl final, casi todo vuelve a lo mismo: construir con intención, quitar ruido y dejar una base que alguien pueda usar, entender y mantener.
", "url": "https://www.bo-labs.com/blog/de-pagina-bonita-a-sistema-mantenible", "title": "De página bonita a sistema mantenible", "summary": "La diferencia entre una web que se ve bien el día uno y una web que puede crecer sin romperse.", "date_modified": "2025-08-27T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/disenar-servicios-web-como-paquetes-no-como-listas-sueltas", "content_html": "Hay temas que parecen puramente técnicos hasta que los bajas a una decisión real de proyecto. Ahí es donde se vuelven interesantes.
\n“Diseño web, desarrollo, SEO, mantenimiento” puede ser correcto, pero no explica mucho. Una lista de capacidades no ayuda al cliente a imaginar qué compra ni cómo será trabajar contigo.
\nUn paquete de servicio, en cambio, ordena la promesa: qué problema resuelve, qué incluye, qué no incluye y qué resultado esperar.
\nCuando el servicio tiene proceso, entregables y límites, la conversación cambia. Ya no todo es abstracto. El cliente entiende fases, tiempos y tipo de decisión.
\nEso no significa hacer ofertas rígidas. Significa poner suelo bajo los pies.
\nMe gusta diseñar servicios como si fueran pequeños productos: nombre claro, intención, estructura y experiencia.
\nLa web no solo muestra lo que haces. También enseña cómo piensas.
\nAl final, casi todo vuelve a lo mismo: construir con intención, quitar ruido y dejar una base que alguien pueda usar, entender y mantener.
", "url": "https://www.bo-labs.com/blog/disenar-servicios-web-como-paquetes-no-como-listas-sueltas", "title": "Diseñar servicios web como paquetes, no como listas sueltas", "summary": "Un servicio se entiende mejor cuando tiene promesa, alcance, proceso, entregables y límites claros.", "date_modified": "2025-07-30T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/por-que-no-todo-necesita-un-formulario-de-contacto", "content_html": "Hay temas que parecen puramente técnicos hasta que los bajas a una decisión real de proyecto. Ahí es donde se vuelven interesantes.
\nDurante años hemos puesto formularios de contacto casi por reflejo. Nombre, email, mensaje, botón. Pero no siempre es lo mejor.
\nEn muchos portfolios o servicios profesionales, la persona quiere escribir directamente, abrir el correo, ver disponibilidad o entender qué pasará después.
\nUn formulario malo parece simple pero añade dudas: ¿ha llegado?, ¿quién lo lee?, ¿cuándo responden?, ¿puedo adjuntar algo? Un enlace de email bien presentado puede ser más claro.
\nLa clave es diseñar la página de contacto como una invitación, no como un trámite.
\nLo usaría si necesitas datos estructurados, cualificar leads, automatizar respuestas o conectar con CRM. Si no, quizá el formulario solo estorba.
\nQuitar una pieza también puede ser diseño.
\nAl final, casi todo vuelve a lo mismo: construir con intención, quitar ruido y dejar una base que alguien pueda usar, entender y mantener.
", "url": "https://www.bo-labs.com/blog/por-que-no-todo-necesita-un-formulario-de-contacto", "title": "Por qué no todo necesita un formulario de contacto", "summary": "A veces quitar el formulario mejora la experiencia: menos fricción, más claridad y contacto directo cuando tiene sentido.", "date_modified": "2025-07-02T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/seo-tecnico-para-portfolios-y-webs-pequenas", "content_html": "Hay temas que parecen puramente técnicos hasta que los bajas a una decisión real de proyecto. Ahí es donde se vuelven interesantes.
\nEn una web pequeña, el SEO técnico muchas veces es sentido común bien aplicado. Títulos claros, descripciones honestas, URLs limpias, contenido entendible y una web que carga rápido.
\nNo hace falta fingir que cada portfolio compite con un medio gigante. Pero sí hace falta no bloquearse a uno mismo.
\nSitemap, robots, canonical, Open Graph, imágenes sociales, etiquetas correctas y estructura semántica. Son cosas poco vistosas, pero cuando faltan se nota.
\nTambién importa que cada página tenga una intención. Home, servicios, trabajos, sobre mí, contacto y blog no deberían repetir el mismo mensaje.
\nEl blog puede reforzar autoridad si habla de problemas reales. No hace falta publicar por publicar. Mejor piezas concretas sobre decisiones, procesos y aprendizajes.
\nEl SEO bueno no es ruido. Es claridad indexable.
\nAl final, casi todo vuelve a lo mismo: construir con intención, quitar ruido y dejar una base que alguien pueda usar, entender y mantener.
", "url": "https://www.bo-labs.com/blog/seo-tecnico-para-portfolios-y-webs-pequenas", "title": "SEO técnico para portfolios y webs pequeñas", "summary": "Lo básico que una web pequeña debería tener bien resuelto: metadatos, estructura, sitemap, robots, rendimiento y contenido útil.", "date_modified": "2025-06-04T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/keystatic-para-webs-estaticas-edicion-simple-sin-perder-rendimiento", "content_html": "Hay un punto medio muy interesante entre una web completamente estática y un CMS grande con base de datos, usuarios, servidor, roles complejos y mantenimiento extra.
\nEse punto medio es justo donde Keystatic puede tener sentido: contenido en archivos, edición visual, control por Git y una web que sigue pudiendo ser rápida, estática y fácil de desplegar.
\nMuchos proyectos pequeños no necesitan un CMS enorme. Necesitan editar páginas, servicios, proyectos, artículos, imágenes y algunos textos globales. Nada más.
\nPero tampoco es cómodo pedir al cliente que edite JSON o MDX a mano. Ahí aparece la necesidad de una interfaz de edición, aunque el proyecto no justifique montar una arquitectura pesada.
\nKeystatic resuelve bien esa tensión: permite tener contenido estructurado, editable desde un panel, pero guardado en el repositorio. Eso significa que el contenido forma parte del código, tiene historial y dispara despliegues como cualquier otro cambio.
\nMe gusta mucho la idea de que el contenido viva en Git. No para todos los casos, pero sí para portfolios, webs corporativas, blogs pequeños y proyectos donde el contenido cambia con calma.
\nTener contenido versionado permite revisar cambios, volver atrás, entender qué se modificó y no depender de una base de datos para algo que puede ser estático.
\nTambién encaja bien con una filosofía de rendimiento: si el sitio puede generarse en build time, no hay necesidad de consultar un servidor por cada visita.
\nLa parte delicada es configurar bien el CMS. Si metes todo en una colección gigante, el editor se vuelve incómodo. Si separas demasiado, se vuelve burocrático.
\nLo que funciona mejor es pensar en cómo editará realmente la persona: páginas por separado, navegación, shared UI, proyectos, servicios, blog, SEO y contenido repetible. Cada cosa en su sitio.
\nUn buen CMS no solo guarda datos. Reduce ansiedad. La persona entra, sabe dónde tocar y entiende qué va a cambiar.
\nA veces se confunde web estática con web inmóvil. No es así. Una web estática puede tener blog, proyectos, imágenes, SEO, idiomas, RSS, sitemap y contenido editable. Lo que cambia es cuándo se construye: en deploy, no en cada request.
\nEso suele ser ideal para portfolios y webs de servicios: muy rápido para el usuario, sencillo de hospedar y con menos piezas que vigilar.
\nKeystatic no lo usaría para todo. Si necesitas permisos editoriales avanzados, workflows complejos, miles de registros, búsquedas internas enormes o contenido en tiempo real, probablemente miraría Payload, Sanity, WordPress, Supabase u otra opción.
\nPero para una web que quiere ser editable sin perder performance, me parece una herramienta muy honesta.
\nLa gracia de Keystatic está en no sobreactuar. Da edición donde hace falta, mantiene el contenido cerca del repo y permite que la web siga siendo ligera.
\nPara mí, esa es una buena dirección: autonomía para el cliente, control para el proyecto y menos infraestructura cuando no aporta valor.
", "url": "https://www.bo-labs.com/blog/keystatic-para-webs-estaticas-edicion-simple-sin-perder-rendimiento", "title": "Keystatic para webs estáticas: edición simple sin perder rendimiento", "summary": "Una forma ligera de dar edición de contenido a una web estática sin convertirla en una aplicación pesada.", "date_modified": "2025-05-07T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/que-debe-poder-editar-un-cliente-en-su-cms", "content_html": "Hay temas que parecen puramente técnicos hasta que los bajas a una decisión real de proyecto. Ahí es donde se vuelven interesantes.
\nCuando un cliente pide “quiero editarlo todo”, lo entiendo. Nadie quiere depender de un desarrollador para cambiar un texto. Pero abrirlo todo sin criterio puede convertir la web en una zona frágil.
\nUn CMS útil no da libertad infinita. Da autonomía segura.
\nAbriría textos, imágenes, servicios, proyectos, artículos, SEO básico, CTAs, FAQs y datos que cambian con frecuencia. También estructuras repetibles donde el cliente entiende el patrón.
\nProtegería layout crítico, componentes delicados, lógica, relaciones complejas y estilos que sostienen la identidad visual.
\nEl editor también es producto. Si el cliente entra y entiende qué tocar, el proyecto vive mejor. Si entra y todo parece un panel técnico, acabará volviendo al WhatsApp.
\nLa mejor edición es la que no da miedo.
\nAl final, casi todo vuelve a lo mismo: construir con intención, quitar ruido y dejar una base que alguien pueda usar, entender y mantener.
", "url": "https://www.bo-labs.com/blog/que-debe-poder-editar-un-cliente-en-su-cms", "title": "Qué debe poder editar un cliente en su CMS", "summary": "No todo debería estar abierto en un CMS. La clave está en dar autonomía donde aporta valor y proteger la experiencia donde hace falta.", "date_modified": "2025-04-09T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/modelar-contenido-bien-evita-dolores-despues", "content_html": "Hay temas que parecen puramente técnicos hasta que los bajas a una decisión real de proyecto. Ahí es donde se vuelven interesantes.
\nInstalar un CMS es fácil. Modelar contenido bien no tanto. La diferencia se nota meses después, cuando el cliente intenta editar algo y todo depende de hacks, campos ambiguos o bloques que sirven para demasiadas cosas.
\nUn buen modelo de contenido define límites. Qué es una página, qué es un servicio, qué es una ruta, qué es una tarjeta, qué se reutiliza y qué no.
\nCuando el contenido tiene relaciones reales, conviene respetarlas. Una ruta no debería duplicar paradas en texto si las paradas existen como entidad. Un proyecto no debería esconder su stack en una descripción si luego quieres filtrarlo o mostrarlo bien.
\nEsa estructura permite que el diseño sea más limpio y que el CMS sea menos peligroso.
\nEl objetivo no es que todo sea editable. El objetivo es que lo importante sea editable sin romper la experiencia.
\nEse matiz cambia todo.
\nAl final, casi todo vuelve a lo mismo: construir con intención, quitar ruido y dejar una base que alguien pueda usar, entender y mantener.
", "url": "https://www.bo-labs.com/blog/modelar-contenido-bien-evita-dolores-despues", "title": "Modelar contenido bien evita dolores después", "summary": "El contenido editable no empieza en el editor, empieza en cómo decides separar entidades, campos y relaciones.", "date_modified": "2025-03-12T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/gtfs-rutas-y-horarios-cuando-una-web-deja-de-ser-solo-una-web", "content_html": "Hay temas que parecen puramente técnicos hasta que los bajas a una decisión real de proyecto. Ahí es donde se vuelven interesantes.
\nUna web de transporte no puede tratar rutas y horarios como párrafos sueltos. Una línea tiene sentidos, paradas, trayectos, salidas, fechas especiales y mapas.
\nCuando ese contenido vive como texto, mantenerlo se vuelve frágil. Cuando vive como datos, la web puede empezar a razonar.
\nGTFS ayuda porque trae una estructura común para rutas, trips, stop_times, calendar y stops. Pero importarlo no basta. Hay que convertirlo en un modelo que el CMS pueda editar y el usuario pueda entender.
\nEso implica deduplicar trayectos, agrupar horarios, respetar sentidos y conservar datos originales para poder revisar.
\nEn este tipo de proyecto, la web pública es solo la punta. Debajo hay una capa de contenido estructurado que permite mostrar horarios, próximos buses y paradas sin escribirlo todo a mano.
\nAhí es donde una web empieza a parecer producto.
\nAl final, casi todo vuelve a lo mismo: construir con intención, quitar ruido y dejar una base que alguien pueda usar, entender y mantener.
", "url": "https://www.bo-labs.com/blog/gtfs-rutas-y-horarios-cuando-una-web-deja-de-ser-solo-una-web", "title": "GTFS, rutas y horarios: cuando una web deja de ser solo una web", "summary": "Qué cambia cuando una web pública tiene que mostrar datos reales de transporte, horarios, paradas y recorridos.", "date_modified": "2025-02-12T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/payload-cms-con-postgresql-cuando-el-contenido-necesita-estructura-real", "content_html": "Hay un punto en algunos proyectos donde "necesitamos un CMS" deja de significar "necesitamos editar textos". Empieza a significar otra cosa: necesitamos administrar información estructurada, relaciones, estados, medios, SEO, formularios y datos que tienen que vivir conectados.
\nAhí Payload CMS con PostgreSQL empieza a tener mucho sentido.
\nUna página corporativa sencilla puede vivir perfectamente con un CMS ligero o incluso con contenido en archivos. Pero si el proyecto tiene rutas, paradas, trayectos, horarios, avisos, tarifas, formularios, medios y páginas editables, el contenido ya no es una colección de párrafos.
\nEs un sistema.
\nEn un proyecto como Flarrea Postgre, una ruta no es solo un título. Tiene lineCode, slug, mapas, sentidos, paradas, schedules, fechas especiales y salidas. Una parada tiene código, zona, municipio, coordenadas y datos de origen. Un trayecto tiene paradas en orden, sentido y relación con una línea.
\nEso no debería vivir escondido dentro de rich text.
\nPayload me gusta porque no se siente como una caja externa que tienes que doblar para que encaje. Vive cerca del código, permite definir colecciones, globals, bloques, permisos, campos, hooks y relaciones con bastante control.
\nEso hace que el admin pueda diseñarse como parte del producto. No solo "aquí editas contenido", sino "aquí gestionas lo que la web necesita para funcionar".
\nSi además usas PostgreSQL, el modelo gana peso real. Las relaciones importan. Las migraciones importan. La estructura no depende de documentos sueltos difíciles de razonar. Para proyectos con datos relacionales, eso es una ventaja muy clara.
\nEn Flarrea, una parte interesante fue la importación GTFS. Leer stops, routes, trips, stop_times, calendar y calendar_dates. Convertirlos en rutas, paradas, trayectos y horarios agrupados. Deduplicar patrones para no crear un trayecto por cada viaje. Guardar raw data cuando conviene auditar.
\nEso no es simplemente un script técnico. Es una decisión de producto, porque define cómo el equipo podrá mantener esa información después.
\nUn importador mal pensado solo mueve datos. Uno bien pensado traduce una fuente externa a un modelo editorial y operativo usable.
\nLa otra capa está en el layout builder. Páginas, avisos, bloques de contenido, media, CTA, tarifas, horarios, formularios. El cliente necesita autonomía, pero no debería poder romper todo el sistema visual en cada edición.
\nPor eso los bloques son importantes. Dan libertad dentro de límites. Permiten componer páginas sin convertir cada página en una selva distinta.
\nEste es un equilibrio delicado: suficiente control para que el cliente pueda publicar, suficientes límites para que la web siga pareciendo diseñada.
\nPayload con PostgreSQL me parece especialmente interesante cuando el CMS no es un accesorio, sino parte del producto. Cuando el contenido tiene forma, relaciones y consecuencias.
\nLa clave sigue siendo la misma: modelar bien. Si las entidades están claras, el admin se vuelve cómodo, la web se vuelve más mantenible y el proyecto puede crecer sin convertirse en una colección de apaños.
", "url": "https://www.bo-labs.com/blog/payload-cms-con-postgresql-cuando-el-contenido-necesita-estructura-real", "title": "Payload CMS con PostgreSQL: cuando el contenido necesita estructura real", "summary": "Por qué Payload y PostgreSQL encajan en proyectos donde el contenido deja de ser texto y empieza a ser sistema.", "date_modified": "2025-01-15T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/como-convertir-un-portfolio-en-una-herramienta-comercial", "content_html": "Hay temas que parecen puramente técnicos hasta que los bajas a una decisión real de proyecto. Ahí es donde se vuelven interesantes.
\nUn portfolio que solo enseña capturas deja demasiado trabajo al visitante. La persona ve algo bonito, pero no siempre entiende qué problema resolviste, qué decisiones tomaste o por qué debería confiar.
\nUn portfolio comercial tiene que hacer más: explicar contexto, proceso, resultados y criterio.
\nPrefiero pocos proyectos bien contados que muchos logos sin historia. Un caso con detalle permite mostrar cómo piensas, no solo cómo decoras.
\nAhí entran las capas: reto, solución, stack, decisiones, limitaciones, aprendizaje y resultado. Eso convierte una pieza visual en prueba de capacidad.
\nEl portfolio debe llevar a una conversación natural. No hace falta presionar. Hace falta que la persona piense: esta persona entiende problemas parecidos al mío.
\nCuando eso pasa, la web deja de ser escaparate y empieza a trabajar.
\nAl final, casi todo vuelve a lo mismo: construir con intención, quitar ruido y dejar una base que alguien pueda usar, entender y mantener.
", "url": "https://www.bo-labs.com/blog/como-convertir-un-portfolio-en-una-herramienta-comercial", "title": "Cómo convertir un portfolio en una herramienta comercial", "summary": "Un portfolio no debería ser solo una galería: debería explicar valor, proceso, criterio y motivos para iniciar una conversación.", "date_modified": "2024-12-04T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/diseno-apple-like-aplicado-a-portfolios-pequenos", "content_html": "Hay temas que parecen puramente técnicos hasta que los bajas a una decisión real de proyecto. Ahí es donde se vuelven interesantes.
\nCuando digo Apple-like no pienso en poner fondos blancos, cards grandes y frases minimalistas porque sí. Pienso en una forma de ordenar: foco, aire, jerarquía, detalle y calma.
\nUn portfolio pequeño puede beneficiarse mucho de eso. No necesita parecer una agencia enorme. Necesita que el trabajo se entienda y que la persona detrás parezca confiable.
\nEl truco está en reducir elementos y hacer que cada uno pese. Un buen titular, una imagen real, una tarjeta con contenido útil, botones consistentes y espacios que dejen respirar.
\nSi todo quiere llamar la atención, nada la tiene. Apple suele ganar porque sabe cuándo callarse.
\nPara un portfolio, eso significa presentar pocos proyectos pero con profundidad, explicar decisiones y cuidar el ritmo visual.
\nEl objetivo no es verse caro. Es verse claro, serio y difícil de improvisar.
\nAl final, casi todo vuelve a lo mismo: construir con intención, quitar ruido y dejar una base que alguien pueda usar, entender y mantener.
", "url": "https://www.bo-labs.com/blog/diseno-apple-like-aplicado-a-portfolios-pequenos", "title": "Diseño Apple-like aplicado a portfolios pequeños", "summary": "Qué significa tomar inspiración de Apple sin copiarlo: claridad, aire, foco, imágenes honestas y jerarquía tranquila.", "date_modified": "2024-11-06T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/performance-web-menos-peso-mas-intencion", "content_html": "Hay temas que parecen puramente técnicos hasta que los bajas a una decisión real de proyecto. Ahí es donde se vuelven interesantes.
\nPerformance no empieza cuando abres Lighthouse. Empieza antes: en cuántas cosas decides cargar, cuántas fuentes usas, cuántas animaciones son necesarias y cuánto peso visual metes en una página.
\nUna web rápida suele tener una cosa en común: intención. No intenta hacerlo todo a la vez.
\nA veces se confunde ligereza con pobreza visual. No tiene por qué. Una interfaz puede sentirse premium con buenas decisiones de espacio, tipografía, imagen y movimiento mínimo.
\nLo caro no debería ser el ruido. Lo caro debería ser la claridad.
\nUna web ligera respeta tiempo, batería, conexión y paciencia. También reduce mantenimiento y hace que el proyecto sea más fácil de cuidar.
\nPara mí, optimizar no es recortar por recortar. Es dejar solo lo que ayuda.
\nAl final, casi todo vuelve a lo mismo: construir con intención, quitar ruido y dejar una base que alguien pueda usar, entender y mantener.
", "url": "https://www.bo-labs.com/blog/performance-web-menos-peso-mas-intencion", "title": "Performance web: menos peso, más intención", "summary": "Rendimiento no es solo una métrica técnica: es claridad, respeto por el usuario y mejor mantenimiento.", "date_modified": "2024-10-09T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/nextjs-astro-o-wordpress-como-elegir-sin-casarte-con-el-stack", "content_html": "Hay temas que parecen puramente técnicos hasta que los bajas a una decisión real de proyecto. Ahí es donde se vuelven interesantes.
\nNext.js, Astro y WordPress pueden ser buenas elecciones. También pueden ser malas si se eligen por moda, costumbre o miedo.
\nLa tecnología correcta depende de cómo vive el proyecto: quién edita, cuántas veces cambia, qué tan interactivo es, qué rendimiento necesita y quién lo mantendrá después.
\nSi es una web de contenido, ligera y con pocas interacciones, miro Astro. Si necesita aplicación, datos dinámicos o una experiencia React más rica, miro Next.js. Si el cliente necesita edición familiar y el proyecto encaja, WordPress sigue siendo válido.
\nY si hay contenido estructurado serio, puede entrar Payload, Keystatic u otro CMS según el caso.
\nUna buena decisión técnica también dice no. No todo necesita servidor. No todo necesita CMS. No todo necesita React. Pero tampoco todo debe ser estático.
\nEl oficio está en ajustar la herramienta al problema real.
\nAl final, casi todo vuelve a lo mismo: construir con intención, quitar ruido y dejar una base que alguien pueda usar, entender y mantener.
", "url": "https://www.bo-labs.com/blog/nextjs-astro-o-wordpress-como-elegir-sin-casarte-con-el-stack", "title": "Next.js, Astro o WordPress: cómo elegir sin casarte con el stack", "summary": "Una forma práctica de elegir tecnología según contenido, edición, rendimiento, mantenimiento y crecimiento real del proyecto.", "date_modified": "2024-09-11T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/headless-cms-explicado-sin-vender-humo", "content_html": "Hay temas que parecen puramente técnicos hasta que los bajas a una decisión real de proyecto. Ahí es donde se vuelven interesantes.
\nUn CMS headless separa el lugar donde editas contenido del lugar donde se muestra. El CMS guarda y organiza. El front-end decide cómo presentar.
\nEso puede ser muy potente, pero no es magia. Si el proyecto no necesita esa separación, puede ser solo otra capa que mantener.
\nTiene sentido cuando hay varios canales, contenido complejo, necesidad de rendimiento alto o una experiencia visual que no quieres limitar a una plantilla.
\nTambién cuando el cliente necesita autonomía editorial pero el front-end debe sentirse premium, rápido y muy controlado.
\nUn headless CMS exige modelar bien el contenido. Si solo replicas campos sin pensar, no ganas mucho. El valor está en convertir contenido en piezas claras, reutilizables y fáciles de componer.
\nLa tecnología ayuda. El criterio decide.
\nAl final, casi todo vuelve a lo mismo: construir con intención, quitar ruido y dejar una base que alguien pueda usar, entender y mantener.
", "url": "https://www.bo-labs.com/blog/headless-cms-explicado-sin-vender-humo", "title": "Headless CMS explicado sin vender humo", "summary": "Qué significa realmente usar un CMS headless, cuándo aporta valor y cuándo solo añade una capa innecesaria.", "date_modified": "2024-08-14T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/wordpress-si-pero-no-siempre-como-web-completa", "content_html": "Hay temas que parecen puramente técnicos hasta que los bajas a una decisión real de proyecto. Ahí es donde se vuelven interesantes.
\nHe trabajado mucho con WordPress y no me interesa vender la idea de que está muerto. No lo está. Sigue siendo una herramienta muy cómoda para editar contenido, gestionar usuarios y resolver webs con rapidez.
\nEl problema aparece cuando se usa por inercia. Cuando una web sencilla acaba con tema pesado, diez plugins y una experiencia lenta solo porque era lo conocido.
\nLa pregunta no es “WordPress sí o no”. La pregunta es qué papel debe jugar. Puede ser la web completa, puede ser solo el CMS, o puede que no haga falta.
\nEn algunos proyectos, WordPress completo tiene sentido. En otros, usarlo headless permite mantener la edición familiar y construir un front-end más rápido y controlado.
\nMe gusta pensar en WordPress como una herramienta, no como una identidad. Si aporta autonomía al cliente y no penaliza la experiencia, perfecto. Si añade peso sin necesidad, toca buscar otra base.
\nEl stack debe servir al proyecto, no al revés.
\nAl final, casi todo vuelve a lo mismo: construir con intención, quitar ruido y dejar una base que alguien pueda usar, entender y mantener.
", "url": "https://www.bo-labs.com/blog/wordpress-si-pero-no-siempre-como-web-completa", "title": "WordPress sí, pero no siempre como web completa", "summary": "WordPress sigue siendo útil, pero conviene decidir si debe ser todo el sistema o solo la capa editorial.", "date_modified": "2024-07-17T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/por-que-una-buena-web-empieza-antes-del-diseno", "content_html": "Hay temas que parecen puramente técnicos hasta que los bajas a una decisión real de proyecto. Ahí es donde se vuelven interesantes.
\nA veces se empieza una web preguntando por colores, referencias o animaciones. Todo eso importa, pero llega después. Antes hay que saber qué tiene que conseguir la web.
\nUna web puede ser bonita y fallar si no sabe explicar el negocio. Puede tener buenos componentes y aun así no guiar al usuario. Por eso me gusta empezar ordenando objetivos, público, contenido y fricciones.
\nCuando la estructura está clara, el diseño respira mejor. Sabes qué secciones sobran, qué mensaje debe ir primero y dónde tiene sentido pedir una acción.
\nEl buen diseño no tapa falta de estrategia. La expone. Si el contenido está confuso, una interfaz elegante solo hace que el problema parezca más caro.
\nPara mí, diseñar una web es construir una conversación. La persona llega con una duda, una necesidad o una intuición. La web debe acompañar sin ponerse en medio.
\nAhí empieza todo: no en el color, sino en el orden.
\nAl final, casi todo vuelve a lo mismo: construir con intención, quitar ruido y dejar una base que alguien pueda usar, entender y mantener.
", "url": "https://www.bo-labs.com/blog/por-que-una-buena-web-empieza-antes-del-diseno", "title": "Por qué una buena web empieza antes del diseño", "summary": "Antes de elegir colores o bloques, una web necesita objetivos claros, contenido ordenado y una idea honesta de lo que debe conseguir.", "date_modified": "2024-06-19T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/astro-para-webs-pequenas-rapidez-foco-y-menos-mantenimiento", "content_html": "Hay temas que parecen puramente técnicos hasta que los bajas a una decisión real de proyecto. Ahí es donde se vuelven interesantes.
\nHay proyectos que no necesitan una aplicación completa. Necesitan páginas rápidas, contenido claro y una base que no se vuelva pesada en seis meses. Ahí Astro tiene mucho sentido.
\nMe gusta especialmente para webs corporativas, servicios locales, portfolios y sitios donde el contenido es el centro. Entrega HTML rápido, deja usar componentes cuando hacen falta y evita cargar JavaScript por costumbre.
\nElegir una herramienta más ligera no es quedarse corto. Muchas veces es justo lo contrario: entender el problema y no meter más sistema del necesario.
\nSi una web tiene pocas interacciones, buena parte del trabajo está en estructura, copy, SEO, imágenes, responsive y velocidad. Astro deja centrarse en eso sin pelear con capas de aplicación que no aportan valor.
\nLo usaría cuando el cliente necesita presencia clara, mantenimiento bajo y rendimiento alto. También cuando el contenido cambia poco o puede gestionarse desde una capa simple.
\nPara mí, la pregunta no es si una tecnología es más moderna. La pregunta es si hace el proyecto más claro, más rápido y más fácil de mantener.
\nAl final, casi todo vuelve a lo mismo: construir con intención, quitar ruido y dejar una base que alguien pueda usar, entender y mantener.
", "url": "https://www.bo-labs.com/blog/astro-para-webs-pequenas-rapidez-foco-y-menos-mantenimiento", "title": "Astro para webs pequeñas: rapidez, foco y menos mantenimiento", "summary": "Por qué Astro encaja tan bien en webs corporativas pequeñas, portfolios y proyectos donde el contenido pesa más que la app.", "date_modified": "2024-05-22T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/una-web-local-no-necesita-ser-grande-necesita-ser-clara", "content_html": "Hay temas que parecen puramente técnicos hasta que los bajas a una decisión real de proyecto. Ahí es donde se vuelven interesantes.
\nMuchas webs locales intentan parecer grandes a base de añadir secciones, efectos y frases genéricas. El resultado suele ser lo contrario: más ruido, menos confianza y un usuario que no encuentra lo básico.
\nPara una empresa de reformas, un taller, una clínica o cualquier servicio local, la web tiene una misión bastante concreta: explicar qué haces, dónde trabajas, por qué confiar y cómo contactar.
\nLa estructura importa más que el adorno. Servicios claros, texto directo, llamadas a contacto visibles y una experiencia móvil que no obligue a pelearse con la pantalla. Eso ya cambia mucho.
\nTambién importa la velocidad. Si alguien llega desde Google con una necesidad inmediata, cada segundo de carga y cada bloque confuso restan.
\nUna web local bien hecha no tiene que ganar premios visuales. Tiene que trabajar todos los días. Tiene que responder preguntas, filtrar mejor a los clientes y dar una sensación de profesionalidad honesta.
\nEso para mí es diseño con intención: menos postureo, más utilidad.
\nAl final, casi todo vuelve a lo mismo: construir con intención, quitar ruido y dejar una base que alguien pueda usar, entender y mantener.
", "url": "https://www.bo-labs.com/blog/una-web-local-no-necesita-ser-grande-necesita-ser-clara", "title": "Una web local no necesita ser grande, necesita ser clara", "summary": "Qué debería resolver una web para un negocio local: confianza, servicios entendibles, velocidad y contacto sin fricción.", "date_modified": "2024-04-24T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/lo-que-aprendi-recreando-una-landing-saas-como-linear", "content_html": "Hay temas que parecen puramente técnicos hasta que los bajas a una decisión real de proyecto. Ahí es donde se vuelven interesantes.
\nRecrear una landing como Linear no va de copiar una estética oscura y ya. Va de entender por qué todo parece estar en su sitio: el tamaño de los textos, la distancia entre bloques, el silencio visual, los estados, los detalles mínimos que hacen que una interfaz parezca rápida incluso antes de tocarla.
\nCuando una página SaaS funciona bien, no te grita. Te ordena la cabeza. Te dice qué hace el producto, por qué importa y qué puedes hacer después sin llenar la pantalla de ruido.
\nLa parte más interesante fue trabajar el ritmo. Una landing premium no es una suma de tarjetas bonitas. Es una secuencia: primero promesa, luego prueba visual, luego argumentos, luego confianza. Si el orden falla, el diseño puede estar bien ejecutado y aun así sentirse vacío.
\nTambién aprendí que los pequeños movimientos tienen que tener una razón. Una transición suave puede elevar una interfaz. Una animación gratuita puede romperla.
\nEste tipo de ejercicio me sirve para proyectos reales porque entrena criterio. Cuando diseño una web para un cliente, no quiero llenar secciones porque toca. Quiero saber qué debe sentir el usuario en cada paso.
\nUna web seria no necesita parecer compleja. Necesita parecer inevitable: clara, rápida, bien compuesta y difícil de mejorar quitando cosas.
\nAl final, casi todo vuelve a lo mismo: construir con intención, quitar ruido y dejar una base que alguien pueda usar, entender y mantener.
", "url": "https://www.bo-labs.com/blog/lo-que-aprendi-recreando-una-landing-saas-como-linear", "title": "Lo que aprendí recreando una landing SaaS como Linear", "summary": "Una mirada práctica a lo que enseña reconstruir una landing SaaS premium: ritmo visual, jerarquía, detalle y criterio de producto.", "date_modified": "2024-03-28T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/recreando-landing-page-linear-app", "content_html": "\nRecrear la página de inicio de Linear.app ha sido un desafío emocionante. En este artículo, te guiaré a través del\nproceso de reconstrucción utilizando Next JS, Tailwind CSS, TypeScript, ESLint, Prettier, Husky y PostCSS.\nPrepárate mientras exploramos el mundo de las herramientas y técnicas modernas del desarrollo web.
\nPara este proyecto, opté por Next JS como el framework de React. Sus capacidades de renderizado del lado del\nservidor y su integración perfecta con TypeScript lo convierten en una excelente elección. Tailwind CSS, con su enfoque basado en utilidades,\nse encargará del estilo, asegurando que logremos una precisión perfecta en los píxeles. ESLint y Prettier mantendrán nuestro código limpio y\nlibre de errores, mientras que Husky se asegurará de que nuestros commits cumplan con los estándares predefinidos.\nPor último, PostCSS manejará cualquier necesidad adicional de estilo.
\n\ntype FeaturesProps = {\n children: React.ReactNode;\n color: string;\n colorDark: string;\n};\n\nexport const Features = ({ children, color, colorDark }: FeaturesProps) => {\n const { ref, inView } = useInView({ threshold: 0.2, triggerOnce: false });\n\nInicialicé un nuevo proyecto de Next JS e instalé las dependencias necesarias.\nCon Tailwind CSS configurado y TypeScript listo, creé la estructura básica de la página de inicio.
\nDescomponer la página de inicio de Linear.app en componentes reutilizables fue crucial.\nDesde la sección de héroe hasta los aspectos más destacados de las funciones, cada componente fue meticulosamente elaborado para reflejar el diseño original.
\nexport const HeroImage = () => {\n const { ref, inView } = useInView({ threshold: 0.8, triggerOnce: true });\n const [lines, setLines] = useState<Line[]>([]);\n const timeoutRef = useRef<ReturnType<typeof setTimeout> | null>(null);\n\n const removeLine = (id: string) => {\n setLines((prev) => prev.filter((line) => line.id !== id));\n };\nEl enfoque basado en utilidades de Tailwind CSS me permitió estilizar los componentes rápidamente.\nSu amplio conjunto de clases de utilidad facilitó la obtención del diseño y diseño deseados.
\nAunque el enfoque era principalmente en el desarrollo frontend, agregar interactividad donde fuera necesario fue esencial. Ya sea animaciones de desplazamiento suaves o menús de navegación receptivos, JavaScript impulsó estas funcionalidades.
\nESLint y Prettier jugaron un papel importante en mantener la consistencia del código e identificar posibles problemas desde el principio. Con su ayuda, me aseguré de que la base de código cumpliera con las mejores prácticas y estándares de codificación.
\nContáctame para transformar tu sitio web y llevarlo al siguiente nivel.
", "url": "https://www.bo-labs.com/blog/recreando-landing-page-linear-app", "title": "Recreando Linear.app", "summary": "Recrear la página de inicio de Linear.app ha sido un desafío emocionante. En este artículo, te guiaré a través del proceso de reconstrucción utilizando Next JS, Tailwind CSS, TS, etc..", "date_modified": "2024-03-03T00:00:00.000Z", "author": { "name": "Bogdan Cristian Pușcașu" } }, { "id": "https://www.bo-labs.com/blog/explorando-wordpress-en-la-era-headless-ventajas-y-guia-de-implementacion", "content_html": "En la era moderna, la presencia digital se ha vuelto imprescindible para empresas,\nemprendedores y creadores de contenido. WordPress, como uno de los sistemas de gestión\nde contenido (CMS) más populares y utilizados en el mundo, facilita la creación y\nel mantenimiento de sitios web.
\nLos sitios web, a pesar de ser entidades digitales, tienen una huella ambiental tangible.\nEl impacto medioambiental de un sitio web se origina principalmente de dos fuentes: el consumo de\nenergía y la infraestructura necesaria para mantenerlo en línea.
\nLa elección de un hosting que utilice energías limpias puede disminuir significativamente la huella de carbono de un sitio web.\nSin embargo, muchos proveedores de hosting aún dependen de fuentes de energía que contribuyen a las emisiones de gases de efecto invernadero.
\nEn este contexto, el uso generalizado de WordPress, que potencia aproximadamente el 40% de los sitios web en Internet, merece una evaluación cuidadosa en términos de su contribución al impacto medioambiental global.
\nWordPress, siendo una de las plataformas de gestión de contenido más populares, tiene un impacto significativo en el medio ambiente.\nSu huella ecológica se puede analizar desde varias perspectivas:
\nAunque WordPress como software es relativamente ligero, la huella ecológica de un sitio de WordPress depende en gran medida del servicio de hosting elegido.
\nMuchos sitios de WordPress están alojados en servidores compartidos, que a menudo no utilizan energías renovables.
\nEsto se traduce en un alto consumo de energía no sostenible para mantener estos sitios en funcionamiento.\nAdemás, la popularidad de WordPress significa que hay una gran cantidad de servidores dedicados exclusivamente a alojar estos sitios, lo que incrementa su impacto ambiental.
\nUna de las características más atractivas de WordPress es su flexibilidad, permitiendo a los usuarios añadir funcionalidades a través de plugins y personalizar la apariencia con temas.\nSin embargo, esta personalización puede llevar a un uso excesivo de recursos.
\nLos plugins y temas mal codificados o innecesarios pueden aumentar significativamente la carga de los servidores, resultando en un mayor consumo de energía.\nAdemás, la actualización constante de estos complementos implica un ciclo continuo de desarrollo y despliegue, que a su vez tiene su propia huella de carbono.
\nEn comparación con otras plataformas de gestión de contenido, WordPress puede no ser siempre la opción más eficiente desde el punto de vista energético.\nPlataformas más ligeras o diseñadas con una mayor eficiencia energética en mente pueden representar alternativas más sostenibles, especialmente para sitios web con requisitos menos complejos.
\nEn resumen, la omnipresencia de WordPress en la web contribuye de manera significativa al consumo de energía y a la huella de carbono asociada con el funcionamiento de los sitios web.\nEsta huella se ve exacerbada por prácticas como el uso de servidores no ecológicos, y la implementación de plugins y temas que aumentan la carga del servidor.
\nLa elección de WordPress para alimentar sitios web simples puede compararse a utilizar un cohete para ir a comprar el pan.\nEs un "overkill" en términos de tecnología y recursos para una tarea que requiere mucho menos.
\nUtilizar WordPress para una simple página de aterrizaje o un sitio web de pocas páginas es un exceso comparado con las necesidades reales del sitio.\nEs como llevar un camión de 18 ruedas para transportar una sola caja. WordPress, con sus numerosas funcionalidades, está diseñado para sitios web con contenido dinámico y complejo.\nEn casos donde el contenido cambia poco y las necesidades son básicas, el uso de WordPress resulta en un desperdicio de recursos computacionales y energéticos.
\nLa sobreutilización de WordPress para sitios sencillos conlleva un uso excesivo de energía. Cada instalación de WordPress necesita mantenimiento regular, lo que implica un uso continuo de recursos y actividades de desarrollo que incrementan la huella de carbono.\nEsto es comparable a encender todas las luces de una casa para leer un libro en una habitación.
\nPara sitios web que no requieren la complejidad de WordPress, hay alternativas más adecuadas y ecológicas. Los constructores de sitios web estáticos o las plataformas de hosting especializadas en eficiencia energética pueden ser soluciones más sostenibles. Estas alternativas, al ser más ligeras y menos demandantes en recursos, son como usar una bicicleta en lugar de un coche deportivo para un recorrido corto.
\nEn conclusión, el uso de WordPress para sitios web sencillos es una elección que impacta negativamente en el medio ambiente, similar a usar herramientas o vehículos excesivamente potentes para tareas simples.\nLa consideración de alternativas más eficientes y respetuosas con el medio ambiente es crucial en estos casos.
\nDada la importancia de minimizar el impacto medioambiental de los sitios web, es crucial explorar alternativas a WordPress, especialmente para sitios que no requieren su nivel de complejidad.\nA continuación, se presentan algunas opciones más sostenibles:
\nLos generadores de sitios estáticos como Astro, NextJS o Gatsby ofrecen una forma eficiente de crear sitios web.\nAl no requerir una base de datos o procesamiento intensivo del servidor, estos sitios consumen menos recursos, reduciendo su huella de carbono.\nSon ideales para sitios con contenido que no cambia frecuentemente.
\nElegir un proveedor de hosting que utilice energías renovables puede tener un impacto significativo en la reducción de la huella de carbono de un sitio web.\nEstos proveedores se centran en la sostenibilidad, utilizando fuentes de energía más limpias y eficientes.\nOptimización y Mantenimiento
\nPara los sitios que deben usar WordPress, es esencial optimizarlos.\nEsto incluye elegir temas y plugins eficientes, minimizar el uso de recursos y mantener el sitio actualizado y seguro. La optimización puede reducir la cantidad de energía necesaria para ejecutar y mantener el sitio.
\nFomentar la conciencia sobre el impacto medioambiental de las tecnologías web es crucial.\nEducar a los desarrolladores, diseñadores y propietarios de sitios web sobre prácticas sostenibles puede llevar a decisiones más informadas y ecológicas.
\nImplementar estas alternativas y estrategias puede marcar una diferencia significativa en la reducción del impacto medioambiental de los sitios web.\nEs un paso hacia un internet más sostenible y respetuoso con el medio ambiente.
\nLa era digital, aunque invisible a simple vista, tiene un impacto significativo en el medio ambiente. El uso excesivo y a menudo innecesario de plataformas como WordPress para sitios web sencillos contribuye a este problema.\nEs comparable a utilizar herramientas excesivamente potentes para tareas sencillas, resultando en un consumo innecesario de energía y un aumento de la huella de carbono.
\nSin embargo, existen alternativas más sostenibles y eficientes energéticamente. Optar por generadores de sitios estáticos para proyectos más simples, elegir proveedores de hosting ecológicos, y educar a la comunidad web sobre prácticas sostenibles, son pasos fundamentales hacia un internet más respetuoso con el medio ambiente. La conciencia y la acción en este ámbito pueden llevar a un cambio significativo y necesario.
\nEs esencial que desarrolladores, diseñadores y propietarios de sitios web consideren el impacto medioambiental de sus decisiones tecnológicas y opten por soluciones que equilibren las necesidades funcionales con la responsabilidad ecológica.
\n¿Estás listo para pasar tu website a una arquitectura verde y amigable con el medio ambiente?
\nContáctame para transformar tu sitio web y llevarlo al siguiente nivel.
¿Que espero yo en 2024?
\nEn el dinámico mundo del desarrollo web, la combinación de un CMS sin cabeza (Headless CMS) con frameworks modernos como Next.js y Astro está revolucionando la forma en que creamos y gestionamos contenido en línea.
\n
Esta poderosa sinergia ofrece una flexibilidad sin precedentes, un rendimiento mejorado y una experiencia de usuario optimizada. En este artículo, exploraremos las ventajas clave de esta integración.
\nasync function fetchGraphQL(query) {\n return fetch(\n `https://graphql.contentful.com/content/v1/spaces/${process.env.CONTENTFUL_SPACE_ID}`,\n {\n method: "POST",\n headers: {\n "Content-Type": "application/json",\n Authorization: `Bearer ${process.env.CONTENTFUL_ACCESS_TOKEN}`,\n },\n body: JSON.stringify({ query }),\n }\n ).then((response) => response.json());\n}\nUn Headless CMS separa el contenido del diseño frontend, permitiendo a los desarrolladores utilizar cualquier framework o tecnología para la presentación.
\nCon Next.js, se puede aprovechar el renderizado del lado del servidor para sitios web dinámicos y con Astro, para sitios estáticos de alto rendimiento. Esta flexibilidad permite a los equipos elegir la mejor herramienta para cada proyecto, sin estar limitados por las restricciones del CMS.
\nEl uso de un Headless CMS con Next.js o Astro contribuye significativamente a un rendimiento web mejorado. Al servir contenido a través de una API y generar páginas estáticas o server-side renderizadas, se reduce el tiempo de carga, mejorando la experiencia del usuario y la visibilidad en motores de búsqueda.
\nAstro, en particular, está diseñado para entregar sitios extremadamente rápidos, optimizando automáticamente la carga de JavaScript.
\nUn Headless CMS, al estar desacoplado del frontend, ofrece una mayor seguridad y escalabilidad.
\nLos riesgos de seguridad asociados con los CMS tradicionales, como los ataques de inyección de SQL, se minimizan.
\nAdemás, la escalabilidad se maneja más eficientemente, ya que el contenido y la presentación se pueden escalar independientemente.
\nLa combinación de un Headless CMS con Next.js permite crear experiencias de usuario altamente personalizadas y dinámicas.
\nNext.js facilita la creación de aplicaciones web interactivas con datos en tiempo real, mientras que el Headless CMS proporciona el contenido. Esto resulta en sitios web más atractivos y funcionales, mejorando la retención y conversión de usuarios.
\nUn Headless CMS proporciona una interfaz centralizada para la gestión de contenido, independientemente del número de canales o plataformas.
\nEsto simplifica la tarea de los creadores de contenido, permitiéndoles publicar y actualizar contenido de manera eficiente, sin preocuparse por los detalles técnicos del frontend.
\nLa combinación de un Headless CMS con frameworks como Next.js y Astro representa una evolución en el desarrollo web. Ofrece una mayor flexibilidad, mejora del rendimiento, seguridad, escalabilidad, y una experiencia de usuario más rica.
\nPara desarrolladores y empresas que buscan estar a la vanguardia, esta integración es una estrategia poderosa y futurista.
\n¿Estás listo para pasar a headless?
\nContáctame para transformar tu sitio web y llevarlo al siguiente nivel.
WordPress, conocido tradicionalmente como un sistema de gestión de contenidos (CMS) completo, ha evolucionado.\nHoy en día, su uso como un Headless CMS está ganando popularidad, ofreciendo a los desarrolladores mayor\nflexibilidad, y a los usuarios finales, experiencias digitales más ricas.\nEn este artículo, exploraremos las ventajas de usar WordPress como un Headless CMS,\nel proceso de implementación y proporcionaremos un ejemplo de código para empezar.
\n\nfunction WordPressPost() {\n const [post, setPost] = useState(null);\n\n useEffect(() => {\n fetch('https://tuwordpress.com/wp-json/wp/v2/posts/1')\n .then(response => response.json())\n .then(data => setPost(data));\n }, []);\n\n if (!post) return <div>Cargando...</div>;\n\n return (\n <div>\n <h1>{post.title.rendered}</h1>\n <div dangerouslySetInnerHTML={{ __html: post.content.rendered }} />\n </div>\n );\n}\n\nexport default WordPressPost;\n\nEste código es un componente React simple que carga y muestra un post de WordPress usando la API REST de WordPress.
\nWordPress como Headless CMS ofrece una combinación potente de flexibilidad, rendimiento, seguridad y capacidad de integración multiplataforma.
\nAl desacoplar el backend y el frontend, abre un nuevo mundo de posibilidades para los desarrolladores y una experiencia mejorada para los usuarios.
\n¿Estás listo para pasar a headless?
\nContáctame para transformar tu sitio web y llevarlo al siguiente nivel.
En un mundo donde la tecnología avanza a pasos agigantados, el campo del diseño y desarrollo web no se queda atrás.\nCada año, emergen nuevas tendencias que transforman la manera en que interactuamos con los sitios web.
\nexport const meta = {\n autor: 'Bogdan Pușcașu',\n fecha: '14-07-2023',\n title: 'Tendencias ascendentes en el diseño y desarrollo web',\n descripción:\n 'En un mundo donde la tecnología avanza a pasos agigantados...[]'\n }\nEn este artículo, exploraremos las tendencias más innovadoras en diseño web para el año 2024,\nesenciales para cualquier diseñador y desarrollador web que busque mantenerse al frente en esta industria dinámica.
\nEl minimalismo, una tendencia eterna en el diseño web, continúa evolucionando. Este año, veremos sitios que adoptan un enfoque aún más simplificado, con amplios espacios blancos. Estos espacios no solo mejoran la legibilidad, sino que también crean una experiencia visualmente relajante para el usuario. El diseño web minimalista enfatiza en lo esencial, eliminando elementos superfluos que puedan distraer al usuario.
\nCon el creciente uso de dispositivos móviles para acceder a internet, el enfoque móvil-primero en el desarrollo web se ha vuelto crucial. Un diseño web responsivo asegura que el contenido se vea y funcione perfectamente en todos los dispositivos. Este año, los diseñadores y desarrolladores web deben priorizar la adaptabilidad y la fluidez del diseño en diferentes tamaños de pantalla, garantizando así una experiencia de usuario óptima.
\nLa inteligencia artificial (IA) está redefiniendo las interacciones en línea. Los chatbots, impulsados por IA, se están convirtiendo en un elemento común en muchos sitios web. Ofrecen una interacción inmediata con los usuarios, respondiendo a consultas y mejorando la experiencia del cliente. Esta integración no solo mejora la eficiencia sino que también añade un toque personalizado al sitio web.
\n \n// Create an OpenAI API client (that's edge friendly!)\nconst openai = new OpenAI({\n apiKey: process.env.OPENAI_API_KEY\n})\nLas animaciones son una poderosa herramienta para captar la atención del usuario.
\nEste año, veremos una mayor implementación de microinteracciones: pequeñas animaciones que ocurren cuando un usuario interactúa con un elemento del sitio.
\nEstas microinteracciones mejoran la usabilidad y hacen que la navegación sea más intuitiva y agradable.\\
En un mundo donde la seguridad de los datos es primordial, el diseño y desarrollo web seguro es más importante que nunca. Los diseñadores web deben asegurarse de que sus sitios cumplan con las normativas vigentes, como el GDPR. Implementar prácticas de seguridad robustas no solo protege a los usuarios, sino que también mejora la confianza y la credibilidad del sitio.
\nLos colores juegan un papel crucial en el diseño web. Este año, esperamos ver una paleta de colores más atrevida y vibrante en los sitios web. Los esquemas de colores audaces y expresivos pueden ayudar a que un sitio web destaque y transmita su mensaje de manera más eficaz.
\nMantenerse al día con estas tendencias emergentes en diseño y desarrollo web no solo es esencial para crear sitios atractivos y funcionales, sino también para ofrecer una experiencia de usuario excepcional. Como diseñadores y desarrolladores, es nuestro deber integrar estas innovaciones en nuestros proyectos, asegurando que nuestros sitios no solo sean estéticamente agradables, sino también eficientes y seguros.
\n¿Estás buscando actualizar tu sitio web con las últimas tendencias de diseño?
\nContáctame para transformar tu sitio web y llevarlo al siguiente nivel.