FactuPlanPlataforma de facturación electrónica para el SRI de Ecuador

Desarrollador web y de aplicaciones en Azirgo SAS. Trabajé en el frontend del panel y, sobre todo, en el sitio web público: contenido y blog, estructura SEO, UX/UI, medición con Google Analytics y Search Console, y análisis del embudo de captación.

La parte difícil de un SaaS de facturación no es solo emitir comprobantes que el SRI acepte: es que los negocios que necesitan facturar lleguen a la plataforma. El producto ya cumplía la norma, pero el sitio no traía búsquedas propias, no había forma de saber qué páginas generaban impresiones y clics, ni de distinguir una visita curiosa de un negocio que de verdad iba a contratar.

• Frontend del sitio web público: páginas de producto, planes, precios y contacto, con UX/UI orientado a llevar al registro.
• Blog propio sobre facturación electrónica, obligaciones ante el SRI y dudas del contribuyente, como puerta de entrada orgánica.
• Estructura SEO del sitio: jerarquía de páginas por intención de búsqueda, títulos y descripciones, enlazado interno, sitemap y datos estructurados.
• Medición en Google Analytics 4 con eventos propios para cada paso del embudo: visita, registro, plan elegido y contacto.
• Seguimiento en Search Console de clics, impresiones, CTR y posición por consulta, para decidir qué contenido ampliar, cuál reescribir y cuál fusionar.
• Frontend del panel administrativo SaaS multi-tenant, con cada empresa aislada dentro de la misma plataforma.
• Microservicios de generación de PDF de los comprobantes y búsqueda de contribuyentes para validar los datos antes de emitir.
• API GraphQL como capa única de datos del panel, con los documentos almacenados en AWS S3.

• Tratar el sitio como parte del producto y no como un folleto: cada página existe para responder una búsqueda concreta y terminar en un registro.
• El blog ataca la duda real del contribuyente (plazos, tipos de comprobante, errores de rechazo del SRI), porque quien busca eso es exactamente quien necesita facturar.
• Eventos propios en GA4 en vez de conformarse con las páginas vistas: sin un evento por paso no se puede ver dónde se cae el embudo.
• Search Console como fuente de verdad de la demanda: primero se mira qué consultas ya dejan impresiones, después se escribe el contenido.
• Next.js con renderizado en servidor para que blog y páginas comerciales sean rastreables desde el primer despliegue.
• La generación de PDF vive en su propio microservicio, para que un pico de emisión no bloquee la API principal.

• Calificar leads con lo que realmente se puede medir: separar la visita informativa del negocio que sí va a contratar.
• Hacer que el contenido educativo y las páginas comerciales convivan sin canibalizarse en las mismas búsquedas.
• Mantener una medición coherente entre el sitio público y el producto para poder leer el embudo completo de punta a punta.
• El formato de comprobante del SRI no admite aproximaciones: o el documento cumple la especificación o es rechazado.

La plataforma está en producción, con distintas empresas emitiendo sus comprobantes desde el mismo panel, y el sitio funciona como su canal de captación: blog y páginas de intención publicadas y rastreables, embudo instrumentado en GA4 y rendimiento por consulta seguido en Search Console para decidir el siguiente contenido.

• Ver factuplan.com.ec