Sitio web de la Fundación A+
La Fundación A+ forma talento tech en Quibdó y su sitio estaba caído en plena campaña. Diseñé y construí de cero un sitio bilingüe que la fundación administra sola desde Sanity, con un recorrido corto para donantes y estudiantes, pensado para teléfonos de gama de entrada, con planes de donación y actualizaciones automáticas a cada donante.
Un sitio para una fundación no se termina el día que sale. Se termina cuando la fundación puede abrir una convocatoria, cambiar una cifra o publicar una foto sin llamar a nadie.
La Fundación A+ forma a jóvenes, niños y adultos de Quibdó, Chocó, en programación e inteligencia artificial, con una idea que guía todo lo que hace: que el talento del Chocó no tenga que migrar para prosperar. Cuando llegué, su sitio en WordPress estaba caído y el dominio mostraba «This Account has been suspended» en plena campaña. Una auditoría del sitio anterior le dio 2,9 sobre 10, y en móvil tardaba 8,7 segundos en pintar lo principal.
El encargo tenía dos objetivos concretos: captar donantes para TrAIning de 100 a 1000+, el programa insignia, y darle a quien quiere estudiar una ruta clara de inscripción. Diseñé, construí y dejé operando el sitio de punta a punta como design engineer, en unas ocho semanas y 99 commits, trabajando con los directivos de la fundación, dos editoras de contenido, un asesor legal para la política de datos y un contador para las preguntas tributarias.
Empezar de cero, a propósito
La primera decisión fue no migrar nada. El contenido del WordPress no representaba a la fundación y moverlo habría sido cargar con sus problemas. Hacer el sitio de cero permitió empezar por la pregunta de fondo: qué tiene que resolver cada persona que llega. Al donante le importa saber en qué se convierte su aporte; al estudiante, si hay cupo, cuándo cierra y qué necesita para postularse.
De ahí salieron nueve vistas y un recorrido corto. Antes había tres puntos de contacto que se pisaban entre sí y confundían a donantes y beneficiarios; quedaron dos, Contacto e Inscripción. Cada plan de Súmate lleva a Contacto con el plan ya escrito en el mensaje.
Súmate: de página informativa a planes de donantes
En la segunda etapa, Súmate pasó a seguir las guías para donantes que aprobó la fundación. Tiene dos caminos en pestañas. Las personas eligen entre tres planes recurrentes, Impulsa, Construye y Transforma, donde cada uno suma los beneficios del anterior, o hacen una donación única. Las empresas encuentran donación única, aporte recurrente a convenir, beneficios de responsabilidad social y alianzas en especie.
La página explica qué hace posible cada aporte, la ruta de 18 meses que recorre un participante, los beneficios del donante, el Régimen Tributario Especial y, en un modal, los datos para transferir. Hoy los aportes se hacen por transferencia: al elegir un plan, la persona escribe y el equipo le confirma los pasos.
Pensado para teléfonos de gama de entrada
Diseñé para teléfonos de gama de entrada y conexiones inestables. Eso cambió decisiones que en otro proyecto serían de estilo: selects nativos en lugar de componentes personalizados, el anti-spam de Turnstile que solo se carga cuando la persona toca el formulario, la librería 3D que solo se descarga al pasar el puntero, y por eso nunca llega a un teléfono, y una foto en el hero en lugar del video de la plantilla original.
Un sistema de diseño que sale del logo
La fundación ya tenía KolasoDS, su propio sistema de diseño para las comunidades del Pacífico colombiano. Copié sus tokens al proyecto sin instalarlo como dependencia, para no atar el sitio a su ciclo de versiones. La paleta sale del logo: sus seis colores son exactamente los tonos 500 de las seis familias del sistema, Kolasó, Reburú, Pingua, Birimbí, Macumba y Cambambero.
Al revisarlos con criterios de accesibilidad corregí cuatro tokens. El más grave era el anillo de foco, que tenía un contraste de 1,38:1 y quedó en 3,58:1. El primario es Kolasó (#773DBD, 6,15:1); Reburú, con 2,98:1, no pasaba AA como color de texto. El velo del hero está calculado para sostener 6,63:1 incluso en el peor caso, con una foto completamente blanca debajo.
Honestidad en el contenido
Toda sección del sitio es condicional: si no hay contenido, no se pinta. Nunca aparece un «0» ni una banda vacía, así que la fundación puede cargar contenido de a poco sin que el sitio se vea a medio hacer. Lo provisional, en cambio, se marca en pantalla. Saqué los testimonios inventados de la plantilla y descarté un «+24 %» decorativo en las cifras.
Bilingüe sin atajos
Un donante internacional tiene que poder compartir la página de donación en inglés, así que el sitio es bilingüe con URLs y slugs propios por idioma. En Sanity los campos en inglés son obligatorios. La traducción asistida por IA siempre pasa por una persona, porque la guía de voz prohíbe el registro de «ONG anglosajona». La única excepción es la política de datos, donde la versión en español es la vinculante.
El administrador de contenidos: la fundación edita sola
El pedido más claro de los directivos fue no depender de nadie para abrir una convocatoria. Por eso todo el contenido vive en Sanity, con el Studio embebido en el mismo sitio, y abrir o cerrar inscripciones es un solo interruptor. El esquema tiene más de 25 tipos, organizados como la fundación piensa su trabajo: páginas, programas, blog, donantes, cifras, testimonios, aliados, equipo y valores.
Decidí no usar un constructor de páginas por bloques. El orden de las secciones es fijo, porque un constructor hace muy fácil romper el diseño. Lo que sí es libre es el contenido de cada sección.
La guía de uso vive dentro del editor. Cada campo tiene una descripción escrita para quien edita: el texto alternativo es obligatorio y explica para qué sirve, y el botón pide ser «específico y honesto: “Conoce el programa TrAIning”, no “¡Dona ahora!”». Un campo que se puede llenar y no se ve en ninguna parte es una trampa, así que cada campo del esquema aparece en el sitio.
La experiencia de los correos
Cada formulario dispara dos correos, en idiomas distintos a propósito. A la persona le llega una confirmación en el idioma en que llenó el formulario: es lo mínimo después de haberle pedido sus datos. Al equipo le llega un aviso siempre en español, porque quien lo lee está en Quibdó.
Los formularios disparan ocho correos que salen de solo dos plantillas hechas con React Email y enviadas con Resend. Una es para la persona, con la franja de colores del logo y una firma con el lugar. La otra es para el equipo, con todos los datos del envío. Ninguna tiene texto escrito en el código: todo entra ya traducido. Los estilos van en línea y en una tabla de un solo ancho, porque Gmail descarta el estilo del encabezado y Outlook ignora buena parte del CSS moderno.
Contacto: confirmación y aviso interno
Inscripción a un programa
Doble confirmación del boletín
Una suscripción sin confirmar no es una suscripción, así que ese correo no avisa al equipo. Además, la dirección completa va en texto debajo del botón, porque varios clientes de correo corporativos reescriben o bloquean los botones.
Estados de la postulación
El rechazo no tiene plantilla. Decirle a alguien que no quedó merece un correo escrito por una persona del equipo, con el contexto que haga falta.
Actualizaciones a donantes
Una de las promesas de los planes es contarle al donante cómo avanza el programa, y cada plan lo hace a su ritmo: Transforma cada semana, Construye cada quince días, Impulsa cada mes y la donación única cada trimestre. El equipo escribe los boletines en Sanity, que también se publican en la web. El resto es automático.
Un cron diario sincroniza a cada donante con el tema de Resend de su frecuencia y manda cada envío como Broadcast: el boletín tal cual a los semanales y un resumen del periodo a los demás. Separar por temas no fue un capricho: el plan gratuito de Resend permite solo tres segmentos. Una tabla de ejecuciones hace de candado para que un reintento nunca mande dos veces el mismo correo.
Hay beneficios que no son correos, como las postales, los certificados, el regalo anual y los encuentros virtuales, y alguien del equipo tiene que prepararlos a mano. El día 1 de cada mes, el sitio le avisa al equipo cuáles tocan según el plan y la fecha de inicio de cada donante.
Esta parte la construyó un equipo de agentes de IA que dirigí, con roles de UX, backend, frontend y dos rondas de QA.
Stack
| Capa | Herramienta | Para qué |
|---|---|---|
| Framework | Next.js 16 (App Router), React 19, TypeScript | Vistas estáticas con revalidación por tipo de contenido |
| Estilos | Tailwind CSS v4 + tokens de KolasoDS | Sistema propio de la fundación, sin dependencia instalada |
| Componentes | shadcn/ui y bloques adaptados | Base accesible sobre la que se desmontó la plantilla original |
| Contenido | Sanity (Studio embebido) | 25 tipos; la fundación edita todo, incluidas las convocatorias |
| Datos | Supabase | Solo recibe formularios: RLS de solo inserción y protección de datos de menores (Ley 1581 de 2012) |
| Correo | Resend + React Email | Correos transaccionales, boletín con doble confirmación y actualizaciones a donantes por Broadcast |
| Automatización | Vercel Cron | Sincroniza donantes, envía las actualizaciones y avisa los beneficios pendientes |
| Seguridad | Cloudflare Turnstile | Anti-spam que se carga solo al tocar el formulario |
| Idiomas | next-intl | Español e inglés con URLs propias |
| Despliegue | Vercel | Publica en cada merge a main |
Lo que aprendí
Que un sitio para una organización pequeña se diseña tanto para quien lo visita como para quien lo mantiene. La mitad del trabajo de diseño estuvo en el Studio: en los nombres de los campos, en sus descripciones y en qué no se puede romper.
También aprendí a desconfiar de las verificaciones fáciles. Una respuesta 200 no prueba que la página se vea bien, y buscar un texto en el HTML no prueba que se haya renderizado, porque la librería de idiomas serializa todas las traducciones. Esas revisiones encontraron problemas reales antes de salir: un canonical heredado que declaraba cada página duplicado del inicio, un XSS almacenado en los datos estructurados y un componente que salía vacío en las nueve vistas.
Queda trabajo antes del lanzamiento: el aviso de cookies con Consent Mode, la revisión legal de la política de datos, la medición de Lighthouse en producción contra la línea base del sitio anterior y el paso del dominio. Cobrar desde el sitio con Stripe queda para una versión futura; mientras tanto, los aportes se hacen por transferencia y cada plan abre la conversación con el equipo.