Caso seleccionado

Informe 01 / Operaciones de recaudación para organizaciones sin ánimo de lucro

Producto en fase piloto recién lanzado.

01

Donaya

Operaciones de recaudación para organizaciones sin ánimo de lucro

Una plataforma de operaciones de recaudación de fondos para organizaciones sin ánimo de lucro: campañas públicas, registros de colaboradores, pagos, certificados, eventos, seguimiento y revisión administrativa.

1

Hipótesis

Las organizaciones sin ánimo de lucro no necesitan otro botón de donación.

La oportunidad consistía en reunir narrativa pública, campañas, datos de colaboradores, certificados y seguimiento dentro de una experiencia operativa fiable.

Recorrido del colaborador

Pasar de una donación puntual a una relación duradera con cada colaborador.

2

Prototipo codificado

El prototipo se convirtió en un producto operativo real.

El producto abarca micrositios de organizaciones, proyectos, productos, aportaciones recurrentes, pago público, certificados, revisión administrativa, correo, contenido y dominios personalizados.

Producto funcional en su repositorio

Ejecución de producto: flujos funcionales, no maquetas estáticas.

3

Control de lanzamiento

La seguridad, el control y la claridad para el usuario pasaron a formar parte de la definición del producto.

La preparación para el lanzamiento incluyó integridad de pagos, acceso por organización, tokens firmados, límites de subida, solicitudes de privacidad, documentación administrativa, localización, pruebas básicas en producción y controles del despliegue.

Comprobaciones de preparación

La seguridad y la fiabilidad se trataron como requisitos del producto desde el inicio, no como correcciones posteriores.

4

Proceso de mejora

El aprendizaje piloto es más importante que el tráfico público temprano.

Como Donaya es un producto nuevo, su valor se aprecia en lo aprendido durante el piloto, la profundidad funcional, la disciplina de lanzamiento y el proceso creado alrededor de los primeros usuarios.

Proceso de mejora

Decisiones basadas en datos: utilizar el tráfico, los hallazgos de seguridad y las conversaciones del piloto sin exagerar sus conclusiones.

10 apartados
  1. 01 - Brief
  2. 02 - Tesis
  3. 03 - Pantallas
  4. 04 - Estrategia
  5. 05 - Sistema
  6. 06 - Riesgos
  7. 07 - Historias
  8. 08 - Método
  9. 09 - Operaciones y confianza
  10. 10 - Conclusión
El brief de 90 segundos

El problema

Las pequeñas organizaciones gestionan donaciones, datos de colaboradores, certificados, eventos y seguimiento. Cuando estas tareas se reparten entre herramientas desconectadas, resulta difícil demostrar que el dinero, los datos y las revisiones están bajo control.

Lo que diseñé y construí

Una plataforma de recaudación con campañas públicas, pagos, registros de colaboradores, controles administrativos, certificados, eventos y seguimiento, diseñada e implementada directamente en el repositorio del producto.

Lo que demuestra

Que puedo transformar un ámbito ambiguo y sensible en un producto operativo, conectando decisiones de producto, UX, seguridad y mejora posterior al lanzamiento.

Responsable y creador del productoRol
Producto activo en fase pilotoEstado
Pagos, PII, certificadosLímites y controles
Controles de SHIP + OPERATEMétodo de trabajo

01 / Capacidades demostradas

Operaciones sensibles de recaudación con pagos, controles administrativos y procesos de seguimiento.

Donaya muestra cómo convierto un proceso sensible de recaudación en un producto funcional: páginas públicas, controles para cada organización, pagos, certificados, revisión administrativa, gestión de contenidos y seguridad.

Modelo de producto
Operaciones de recaudación para organizaciones sin ánimo de lucro
Punto de entrada al mercado
Posicionamiento de Donaya con 0 % de comisión de plataforma
Pruebas de seguridad y control
Revisión de seguridad, comprobaciones de pago y documentos de cumplimiento
La historia

Un sábado de recaudación, antes y después.

Antes de Donaya, lanzar una campaña podía implicar un enlace de pago en una herramienta, nombres de colaboradores en una hoja de cálculo, certificados preparados a mano y un seguimiento que dependía de la memoria de alguien. La organización era fiable; su flujo de trabajo no conseguía hacerlo visible.

El producto lo resume en un solo camino: publicar una campaña, recibir el pago, registrar al donante, emitir el certificado y crear el seguimiento. El trabajo de diseño consistió menos en añadir pantallas y más en decidir qué acciones requieren revisión, qué registros necesitan límites más estrictos y dónde la organización necesita ver sus operaciones de un vistazo.

El resto del caso desarrolla ese encuadre: las fases, la cascada de decisiones, el trabajo sobre riesgos y los momentos en que el criterio de producto cambió la implementación.

02 / Producto en funcionamiento

Capturas seleccionadas para mostrar cómo funciona el producto, no solo para decorarlo.

Pantallas seleccionadas del producto real.

Capturas del producto en funcionamiento, recortadas para que cada detalle pueda verse con claridad.

Editor de Donaya con la vista previa de una campaña y sus controles de edición.
Fig. 02 - Edición del sitio de la organización con contenido de campaña real.
  1. 1
    Promesa pública junto al control operativo

    El editor mantiene la vista previa junto a los controles, de modo que el texto, la credibilidad visual y la preparación operativa puedan revisarse al mismo tiempo.

  2. 2
    Historia de la campaña y ruta de contribución

    La recaudación se trata como una relación: narrativa, objetivo, mecánica de donación y seguimiento nacen del mismo modelo de producto.

  3. 3
    Control de lanzamiento dentro del flujo de trabajo

    El trabajo no consiste solo en publicar una página. Requiere estados de revisión, límites administrativos y la seguridad de que la experiencia pública refleja la intención de la organización.

Panel de eventos Donaya con métricas de recaudación de fondos y una tabla de gestión de eventos.
OperacionesEventos y estado de recaudación de fondos en un solo espacio de trabajo.

Las tablas, las métricas y la gestión de eventos muestran el trabajo interno que sostiene la experiencia pública.

Editor de proyectos de Donaya con contenido de campaña y vista previa de la página de donación.
Editor de campañaNarrativa del proyecto y mecánica de donación, juntas.

El editor combina narrativa, medios, establecimiento de objetivos y preparación para el pago en lugar de tratar la recaudación de fondos como un botón.

Sistema de tarjetas de agradecimiento de Donaya con distintas plantillas de seguimiento.
SeguimientoUna relación de donante continúa después del pago.

Las plantillas de agradecimiento convierten el seguimiento de colaboradores en una experiencia de producto diseñada de principio a fin.

03 / Cadena de decisiones estratégicas

La cadena de decisiones que define la dirección del producto.

Esta sección explica el producto desde la perspectiva de gestión: para quién es, dónde empieza, cómo puede diferenciarse, qué capacidades necesita y cómo seguirá mejorando.

Aspiración

Convertirse en la herramienta desde la que las organizaciones con una misión social gestionan su recaudación y la relación con sus colaboradores.

Dónde competir

Organizaciones españolas y europeas que necesitan unir recaudación y operaciones con colaboradores.

Cómo ganar

Combinar narrativa pública, pagos, registros de donantes, certificados, controles administrativos y localización.

Capacidades

Stripe, Resend, Supabase, dominios personalizados, revisión de administrador, documentos de cumplimiento, verificaciones de lanzamiento.

Sistema de gestión

Modelo de precios, revisiones de seguridad, automatización del blog, controles básicos en producción y feedback del piloto.

04 / Mapa de producto

Los usuarios, las interfaces y las capacidades que sostienen el producto.

Responsable integral del producto: estrategia, UX, arquitectura, implementación, lanzamiento, seguridad y método de trabajo.

Usuarios

  • Equipos de organizaciones sin ánimo de lucro
  • Colaboradores y donantes
  • Administradores y revisores de cumplimiento

Partes del producto

  • Páginas de organizaciones públicas
  • Pago de donaciones y productos
  • Espacio de creación y administración

Capacidades

  • Pagos
  • Certificados
  • Correo electrónico
  • Dominios personalizados
  • Flujos de trabajo de privacidad

05 / Modelo de riesgos de producto

Valor, usabilidad, viabilidad técnica, viabilidad de negocio y confianza.

El mapa de riesgos muestra qué debía ser cierto antes de poder tratar el producto como algo más que un concepto.

Valor

¿Es este un problema significativo para el usuario?

Las organizaciones sin ánimo de lucro necesitan recaudación de fondos públicos, registros, seguimiento, certificados y visibilidad administrativa en un solo lugar.

Usabilidad

¿Pueden los operadores y los donantes utilizarlo con calma?

La experiencia pública está separada de la gestión interna: el donante ve un recorrido sencillo y la organización conserva el control.

Viabilidad técnica

¿Puede realmente funcionar el sistema?

La aplicación integra pagos, almacenamiento, webhooks, correo, dominios personalizados, localización y comprobaciones básicas.

Viabilidad de negocio

¿Puede el modelo respaldar el negocio?

El caso explora los precios, el posicionamiento de las tarifas de la plataforma, la lógica de facturación y la implementación piloto en lugar de solo la interfaz de usuario.

Confianza

¿Se pueden lanzar de forma responsable los flujos sensibles?

El trabajo de lanzamiento de seguridad cubrió el inventario de rutas, cookies firmadas, límites de carga, webhooks, CSP y herramientas de privacidad.

La lección

La velocidad solo funciona cuando el feedback se estructura.

Donaya muestra que avanzar rápido no consiste solo en producir más. El producto pudo evolucionar con rapidez porque definí desde el principio los datos principales, las responsabilidades de cada usuario, los límites de acceso y los riesgos operativos.

Los comentarios del piloto pasaron a formar parte del desarrollo. Cada uno se clasificó como error, diferencia de expectativas, decisión sobre permisos o nueva función, y se acompañó de pasos para reproducirlo, comprobaciones en vista previa y una respuesta registrada. Así pude aprender de los primeros usuarios sin presentar esos datos como una validación mayor de la que realmente eran.

06 / Historias de aprendizaje de producto

Decisiones concretas que cambiaron el rumbo del producto.

Qué era ambiguo, qué decisión tomé y qué aprendimos de sus resultados.

Cómo funciona

La recaudación necesitaba una herramienta de gestión completa, no solo una página de donaciones.

Restricción
La donación es solo una parte del trabajo. Los equipos también necesitan mantener conectados el contenido de campaña, los registros de colaboradores, los certificados, la venta de productos, los eventos, el seguimiento y la visibilidad administrativa.
Decisión
Modelé Donaya alrededor del ciclo completo del colaborador: narrativa pública, aportaciones, registros, generación de certificados, agradecimientos, controles de organización y revisiones administrativas y de lanzamiento.
Prueba
El piloto permite revisar todo el recorrido, desde la página pública y el pago hasta los registros operativos, los certificados y el seguimiento, sin repartir el trabajo entre herramientas desconectadas.
Feedback del piloto

Los comentarios ambiguos del piloto se convirtieron en un proceso claro de mejora.

Restricción
Los primeros comentarios mezclaban errores, problemas de uso, dudas sobre permisos y peticiones de nuevas funciones. A veces faltaban datos para reproducir el problema.
Decisión
Clasifiqué cada comentario, preparé datos de QA, utilicé versiones de prueba, pedí la información necesaria para reproducir cada problema y mantuve un registro objetivo de los cambios.
Prueba
El proceso transformó comentarios dispersos en correcciones, vistas previas más fieles y una forma más clara de colaborar en futuras pruebas piloto.
Modelo de acceso

Acceso multiusuario sin cuentas compartidas.

Restricción
Las organizaciones reales necesitaban colaboradores, pero los datos de los donantes, los pagos, los certificados y las acciones de cumplimiento hacían que las credenciales compartidas fueran inseguras.
Decisión
Diseñé roles de propietario y administrador, invitaciones enviadas por correo electrónico que vencen, RBAC del lado del servidor, revocación, protección del último propietario, registros de auditoría y límites de operaciones confidenciales.
Prueba
Las organizaciones pueden invitar a colaboradores mientras la facturación, los pagos, las exportaciones y las acciones sensibles al cumplimiento permanecen protegidas.

07 / Relación con el método

Cómo se relaciona este caso con mi método de trabajo.

Cada caso principal muestra el mismo patrón: usar la IA para ampliar la capacidad de ejecución, mantener las decisiones bajo supervisión humana, reducir riesgos y establecer un proceso de mejora continua.

Creación asistida por IA

El brief antes de construir.

El trabajo se apoya en briefs de producto, conocimiento del repositorio, revisión de la implementación, controles de validación y mensajes verificables, no en instrucciones aisladas a la IA.

Criterio de producto

Operaciones sensibles de recaudación con pagos, controles administrativos y procesos de seguimiento.

El caso muestra cómo reduje los riesgos de valor, usabilidad, tecnología y negocio, y qué límites y controles preparé para lanzar el producto con seguridad.

Siguiente etapa de mejora

Producto en fase piloto recién lanzado.

El siguiente paso es reunir mejores datos sobre el uso, los resultados del piloto, los controles operativos, la seguridad y las prioridades del producto.

Leer el Playbook

08 / Del concepto al lanzamiento

Cómo la idea se convirtió en un sistema preparado para su lanzamiento.

  • Lista de verificación de lanzamiento con controles locales, de vista previa y de producción.
  • Proceso de revisión administrativa para organizaciones, documentación, solicitudes de privacidad y registros operativos.
  • Automatización del blog y la localización para apoyar la adquisición y un posicionamiento centrado en el mercado español.
  • El trabajo pendiente de seguridad se separó en bloqueadores de lanzamiento, candidatos de riesgo aceptados y trabajo de defensa en profundidad.

09 / Seguridad y control

Cómo el producto protege a usuarios, datos y operaciones.

  • Cálculo del importe del pago en el servidor y verificación de la firma de los webhooks.
  • Cookies firmadas, rutas protegidas, RBAC, acceso a documentación restringido a administradores y listas de formatos permitidos para las subidas.
  • Trabajo de refuerzo pendiente y documentado, incluidos MFA/SSO, controles CSRF y de origen y más documentación de seguridad para entornos empresariales.

10 / Lo que demuestra

Qué demuestra este caso a un equipo de producto.