DEV Community: A. Garrido Builds

The Silent Billing Bug Every AI-Generated SaaS Has (And How Weekly Stripe Visibility Helps Catch It)

A. Garrido Builds — Tue, 14 Apr 2026 14:51:07 +0000

A post on Indie Hackers this week described something that should scare every founder who built their SaaS with an AI coding tool in the last year.

The pattern: a Stripe webhook handler catches invoice.payment_failed. It returns 200 OK. Stripe marks it as delivered and moves on. But inside the handler, nothing actually happens. No database updated. No access revoked. The user keeps full access to the product — forever.

The founder doesn't notice because their Stripe dashboard shows MRR coming in from other customers. Everything looks fine. The leak only shows up at the intersection of two systems: who failed to pay in Stripe, and who still has active access in the database. Neither system flags the overlap automatically.

This is the most common hidden bug in AI-generated SaaS right now. Tools like Cursor and Lovable are excellent at building the happy path. Checkout works, user gets access, everything looks good. The failure paths — payment fails, subscription cancels, refund issued — are the parts AI tools generate poorly because the tutorials they learned from skip them.

The detection problem

The reason this bug is so hard to catch isn't technical — it's visibility. If you're not actively comparing your failed payment events in Stripe against your active users in your database, the bug is invisible.

Most founders check their Stripe dashboard periodically. They see total MRR, recent charges, maybe a graph. They don't see the intersection of failed payments and active access because Stripe doesn't surface that view by default.

What helps

When I built Autoreport — a tool that sends Stripe founders a weekly PDF every Monday morning — one of the deliberate design choices was to put failed payments, refunds, and disputes in the same report as active customer data. Not because I anticipated this specific bug, but because I wanted founders to see their Stripe week as a complete picture, not just the positive signals.

A weekly report won't replace a proper webhook audit. But it creates a forcing function: every Monday, you see your failed payments side by side with your revenue. If those numbers don't add up over time, something is wrong.

What to check right now

If you built your SaaS with an AI tool, open your webhook handler and find the case for invoice.payment_failed. Look at what's actually inside it. If it logs and returns without touching your database or your user's access state, you have this bug.

The fix is straightforward once you find it. The hard part is knowing to look.

If you want a weekly view of your Stripe data without building a dashboard, Autoreport sends you a PDF every Monday morning.

Why We Built an API for Spanish Fiscal ID Validation Instead of Just Implementing It

A. Garrido Builds — Wed, 01 Apr 2026 15:35:44 +0000

A few months ago I was integrating fiscal identifier validation into a project. I googled it, found a 30-line JavaScript function, copied it, tested it with four cases, and it worked. I dropped it into the codebase and forgot about it.

Three months later, a user emailed us: their CIF wasn't validating. It was a perfectly valid CIF.

That's when I understood there's a difference between implementing validation and maintaining it correctly.

The problem isn't that it's hard

Validating a NIF seems straightforward: 8 digits, one letter, modulo 23. Any developer can implement it in ten minutes.

The problems appear when you scratch the surface:

NIF: the basic algorithm works, but there are special formats — K, L and M NIFs for specific cases — that most implementations simply ignore.

NIE: starts with X, Y or Z, then follows the NIF algorithm with substitution. Most regex you'll find online accept 7 or 8 digits interchangeably, when the correct format depends on the prefix.

CIF: this is where almost everything breaks. The control character can be a letter or a digit depending on the entity type (first letter of the CIF). Most implementations accept either for all types — which is incorrect. Additionally, when (10 - sum % 10) % 10 === 0, the control character should be J in certain cases — an edge case that produces silent bugs that are extremely hard to track down.

IBAN: the MOD-97 algorithm requires arithmetic with very large numbers. In JavaScript you need BigInt, and in environments where it's unavailable or poorly implemented, it fails without a visible error.

None of these bugs surface in development. They surface in production, with real identifiers from real users.

The silent bug is the worst kind of bug

When a validation fails visibly — throws an exception, returns an error — you catch it and fix it. The real problem with fiscal validation bugs is that they accept invalid identifiers without warning.

A user enters a CIF with an incorrect control digit. Your code says "valid". The data goes into the database. Months later, when you try to use that data for a fiscal operation, the problem surfaces — but now you have no idea where it came from.

The maintenance nobody budgets for

Even if you implement everything correctly today, there's another problem: the rules can change.

Spain has updated fiscal identifier formats in the past. NIE formats have evolved. When that happens, someone has to update the code — and that someone might not be the person who wrote it, or be on the same team, or remember why each decision was made.

With an API, that's the API maintainer's problem. You consume the endpoint, they keep the algorithms up to date.

What we built

We built Valix — a REST API that validates NIF, NIE, CIF and IBAN using the official Spanish algorithms, with automatic type detection and a structured JSON response.

import requests

response = requests.post(
    "https://api.getvalix.io/v1/validate/trial",
    json={
        "items": [
            {"value": "12345678Z", "type": "AUTO"},
            {"value": "X1234567L", "type": "AUTO"},
            {"value": "A12345674", "type": "AUTO"},
            {"value": "ES9121000418450200051332", "type": "AUTO"}
        ]
    }
)

result = response.json()
for item in result["results"]:
    status = "valid" if item["valid"] else f"invalid: {', '.join(item['errors'])}"
    print(f"{item['value']} → {item['detected_type']} — {status}")

Output:

12345678Z → NIF — valid
X1234567L → NIE — valid
A12345674 → CIF — valid
ES9121000418450200051332 → IBAN — valid

The trial endpoint requires no registration or API key — 50 validations per day per IP so you can test it before committing to anything.

When does it make sense to implement it yourself?

Being honest: if your validation volume is very low, you're always validating the same identifier type, and you have exhaustive tests with real-world cases, implementing it internally can make sense.

But if you're validating identifiers from production users, mixing types (NIF + NIE + CIF + IBAN), or simply don't want to spend time maintaining this — an API is the more sensible choice.

Resources

API and documentation: getvalix.io
Code examples in Python, JavaScript, PHP and cURL: github.com/getvalix/valix-examples
JavaScript/TypeScript SDK: npm @valix/sdk

Disclaimer: I'm the author of Valix.

Por qué usamos una API para validar NIF, NIE y CIF en vez de implementarlo nosotros mismos

A. Garrido Builds — Wed, 01 Apr 2026 15:32:30 +0000

Hace unos meses estaba integrando validación de identificadores fiscales en un proyecto. Busqué en Google, encontré una función de 30 líneas en JavaScript, la copié, la probé con cuatro casos y funcionó. La metí en el código y la olvidé.

Tres meses después, un usuario nos mandó un email: su CIF no validaba. Era un CIF perfectamente válido.

Ese día entendí que hay una diferencia entre implementar la validación y mantenerla correctamente.

El problema no es que sea difícil

Validar un NIF es sencillo en apariencia: 8 dígitos, una letra, módulo 23. Cualquier dev lo implementa en diez minutos.

El problema aparece cuando rascas un poco:

NIF: el algoritmo básico funciona, pero hay formatos especiales — NIFs K, L y M para casos específicos que muchas implementaciones directamente ignoran.

NIE: empieza por X, Y o Z, luego sigue el algoritmo del NIF con sustitución. La mayoría de regex que encontrarás online aceptan tanto 7 como 8 dígitos indistintamente, cuando el formato correcto depende del prefijo.

CIF: aquí es donde casi todo falla. El dígito de control puede ser una letra o un número dependiendo del tipo de entidad (primera letra del CIF). La mayoría de implementaciones lo aceptan indistintamente para todos los tipos, lo cual es incorrecto. Además, cuando (10 - suma % 10) % 10 === 0, el carácter de control debería ser J en ciertos casos — un edge case que genera bugs silenciosos muy difíciles de detectar.

IBAN: el algoritmo MOD-97 requiere aritmética con números muy grandes. En JavaScript necesitas BigInt, y en entornos donde no está disponible o se implementa mal, falla sin error visible.

Ninguno de estos bugs explota en desarrollo. Explotan en producción, con identificadores reales de usuarios reales.

El bug silencioso es el peor tipo de bug

Cuando una validación falla de forma visible — lanza una excepción, devuelve un error — lo detectas y lo corriges. El problema real con los bugs de validación fiscal es que aceptan identificadores inválidos sin avisar.

Un usuario introduce un CIF con el dígito de control incorrecto. Tu código dice "válido". El dato entra en base de datos. Meses después, cuando intentas hacer una operación fiscal con ese dato, el problema emerge — pero ya no sabes de dónde viene.

El mantenimiento que nadie contabiliza

Aunque implementes todo correctamente hoy, hay otro problema: la normativa puede cambiar.

España ha actualizado el formato de los identificadores fiscales en el pasado. Los formatos de NIE han evolucionado. Cuando eso pasa, alguien tiene que actualizar el código — y ese alguien podría no ser la misma persona que lo escribió, ni estar en el mismo equipo, ni recordar por qué se tomó cada decisión.

Con una API, ese problema es de quien mantiene la API. Tú consumes el endpoint, ellos mantienen los algoritmos actualizados.

Lo que hicimos

Construimos Valix — una API REST que valida NIF, NIE, CIF e IBAN usando los algoritmos oficiales, con detección automática del tipo de identificador y respuesta JSON estructurada.

import requests

response = requests.post(
    "https://api.getvalix.io/v1/validate/trial",
    json={
        "items": [
            {"value": "12345678Z", "type": "AUTO"},
            {"value": "X1234567L", "type": "AUTO"},
            {"value": "A12345674", "type": "AUTO"},
            {"value": "ES9121000418450200051332", "type": "AUTO"}
        ]
    }
)

resultado = response.json()
for item in resultado["results"]:
    estado = "válido" if item["valid"] else f"inválido: {', '.join(item['errors'])}"
    print(f"{item['value']} → {item['detected_type']} — {estado}")

Salida:

12345678Z → NIF — válido
X1234567L → NIE — válido
A12345674 → CIF — válido
ES9121000418450200051332 → IBAN — válido

El endpoint trial no requiere registro ni API key — 50 validaciones diarias por IP para que puedas probarlo antes de comprometerte con nada.

¿Cuándo tiene sentido implementarlo tú mismo?

Siendo honestos: si tu volumen de validaciones es muy bajo, el identificador que validas es siempre el mismo tipo y tienes tests exhaustivos con casos reales, implementarlo internamente puede tener sentido.

Pero si validas identificadores de usuarios de producción, mezclas tipos (NIF + NIE + CIF + IBAN), o simplemente no quieres dedicar tiempo a mantener esto — una API es la opción más sensata.

Recursos

API y documentación: getvalix.io
Ejemplos en Python, JavaScript, PHP y cURL: github.com/getvalix/valix-examples
SDK para JavaScript/TypeScript: npm @valix/sdk

Disclaimer: soy el autor de Valix.

How to Validate Spanish NIF, NIE, CIF and IBAN in Python

A. Garrido Builds — Mon, 30 Mar 2026 16:07:08 +0000

If you've ever built a form or backend system for the Spanish market, you've likely had to validate fiscal identifiers like NIF, NIE, CIF or IBAN. Each one has its own algorithm, edge cases, and validation rules — and implementing them correctly from scratch is surprisingly tricky.

In this article, I'll show you how to validate all four identifier types with a single API call using Python, without having to implement or maintain the validation algorithms yourself.

The Problem with DIY Validation

Spanish fiscal identifiers are more complex than they look:

NIF: 8 digits + 1 letter, validated with a modulo-23 algorithm
NIE: Starts with X, Y or Z, then follows the NIF algorithm with substitution
CIF: Letter + 7 digits + control character (can be a letter or digit depending on the entity type)
IBAN: ES + 2 check digits + 20-digit BBAN, validated with MOD-97

Most implementations online have subtle bugs — incorrect CIF letter validation, missing NIE edge cases, or IBAN check digit errors. Getting it wrong means accepting invalid identifiers or rejecting valid ones.

A Better Approach: Use an API

Valix is a REST API that validates Spanish fiscal identifiers using the official algorithms. It handles NIF, NIE, CIF and IBAN, detects the type automatically, and returns a structured JSON response.

You can try it for free — no registration, no API key required for the trial endpoint.

Getting Started

No libraries to install beyond requests:

pip install requests

Trial: Validate Without Registration

The trial endpoint allows up to 5 identifiers per call and 50 validations per day per IP — no API key needed.

import requests

def validate_identifiers_trial(identifiers: list[str]) -> dict:
    """
    Validate Spanish fiscal identifiers using the Valix trial endpoint.
    No API key required. Max 5 identifiers per call, 50/day per IP.
    """
    url = "https://api.getvalix.io/v1/validate/trial"
    payload = {
        "items": [
            {"value": identifier, "type": "AUTO"}
            for identifier in identifiers
        ]
    }
    response = requests.post(url, json=payload)
    response.raise_for_status()
    return response.json()

# Example usage
identifiers = [
    "12345678Z",               # NIF
    "X1234567L",               # NIE
    "A12345674",               # CIF
    "ES9121000418450200051332" # IBAN
]

result = validate_identifiers_trial(identifiers[:5])  # Max 5 for trial
for item in result["results"]:
    status = "✓ valid" if item["valid"] else "✗ invalid"
    print(f"{item['value']} → {item['detected_type']} {status}")

Output:

12345678Z → NIF ✓ valid
X1234567L → NIE ✓ valid
A12345674 → CIF ✓ valid
ES9121000418450200051332 → IBAN ✓ valid

Production: Batch Validation with API Key

For production use, the batch endpoint supports up to 100 identifiers per call. Get your API key at getvalix.io.

import requests
import os

def validate_batch(identifiers: list[str], api_key: str) -> dict:
    """
    Validate up to 100 Spanish fiscal identifiers in a single API call.
    Requires a valid API key from getvalix.io.
    """
    url = "https://api.getvalix.io/v1/validate/batch"
    headers = {
        "x-api-key": api_key,
        "Content-Type": "application/json"
    }
    payload = {
        "items": [
            {"value": identifier, "type": "AUTO"}
            for identifier in identifiers
        ]
    }
    response = requests.post(url, headers=headers, json=payload)
    response.raise_for_status()
    return response.json()

# Load API key from environment variable (never hardcode it)
api_key = os.environ.get("VALIX_API_KEY")

identifiers = [
    "12345678Z",
    "X1234567L",
    "A12345674",
    "ES9121000418450200051332",
    "99999999R",  # Invalid NIF
]

result = validate_batch(identifiers, api_key)
print(f"Total: {result['total']}")
print(f"Valid: {result['valid_count']}")
print(f"Invalid: {result['invalid_count']}")
print()
for item in result["results"]:
    if item["valid"]:
        print(f"✓ {item['value']} → {item['detected_type']}")
    else:
        print(f"✗ {item['value']} → {', '.join(item['errors'])}")

Output:

Total: 5
Valid: 4
Invalid: 1

✓ 12345678Z → NIF
✓ X1234567L → NIE
✓ A12345674 → CIF
✓ ES9121000418450200051332 → IBAN
✗ 99999999R → Formato inválido

Understanding the Response

Each result includes:

{
  "index": 0,
  "value": "12345678Z",
  "requested_type": "AUTO",
  "detected_type": "NIF",
  "valid": true,
  "formatted": "12345678Z",
  "errors": []
}

detected_type: the actual identifier type (NIF, NIE, CIF, IBAN)
valid: boolean result
formatted: normalized version of the identifier
errors: list of validation error messages if invalid

For CIF identifiers, the response also includes entity_type — the type of Spanish business entity (e.g. "Sociedad Anónima").

Handling Errors Gracefully

import requests
from requests.exceptions import HTTPError

def validate_with_error_handling(identifiers: list[str], api_key: str) -> dict | None:
    try:
        return validate_batch(identifiers, api_key)
    except HTTPError as e:
        if e.response.status_code == 401:
            print("Invalid or missing API key")
        elif e.response.status_code == 429:
            print("Monthly validation limit exceeded")
        elif e.response.status_code == 400:
            error_data = e.response.json()
            print(f"Bad request: {error_data.get('error')}")
        else:
            print(f"API error: {e}")
        return None

Type-Specific Validation

If you already know the type of identifier you're validating, you can pass it explicitly instead of using AUTO:

payload = {
    "items": [
        {"value": "12345678Z", "type": "NIF"},
        {"value": "X1234567L", "type": "NIE"},
        {"value": "A12345674", "type": "CIF"},
        {"value": "ES9121000418450200051332", "type": "IBAN"}
    ]
}

This is useful when your data source already provides the identifier type, or when you want to enforce a specific type validation.

Using JavaScript instead of Python?

Valix has an official JavaScript/TypeScript SDK available as an npm package:

npm install @valix/sdk

→ @valix/sdk on npm
→ SDK JS repository

Code Examples

Full usage examples in multiple languages (Python, JavaScript, PHP, cURL) are available in the official examples repository:

→ github.com/getvalix/valix-examples

Pricing

Plan	Price	Validations/month
Trial	Free	50/day, no registration
Starter	€19/month	10,000
Growth	€49/month	100,000
Pro	€149/month	1,000,000

Summary

Validating Spanish fiscal identifiers correctly requires implementing multiple complex algorithms with edge cases that are easy to get wrong. Using Valix gives you:

Accurate validation based on official algorithms
Automatic type detection
Batch processing up to 100 identifiers per call
A free trial to test before committing

Try it at getvalix.io — the trial endpoint requires no registration.

Cómo validar NIF, NIE, CIF e IBAN en Python

A. Garrido Builds — Mon, 30 Mar 2026 16:00:36 +0000

Si has desarrollado alguna vez un formulario o backend para el mercado español, probablemente hayas tenido que validar identificadores fiscales como el NIF, NIE, CIF o IBAN. Cada uno tiene su propio algoritmo, casos especiales y reglas de validación — e implementarlos correctamente desde cero es más complicado de lo que parece.

En este artículo te muestro cómo validar los cuatro tipos con una sola llamada API usando Python, sin tener que implementar ni mantener los algoritmos de validación.

El problema de implementar la validación tú mismo

Los identificadores fiscales españoles son más complejos de lo que aparentan:

NIF: 8 dígitos + 1 letra, validado con un algoritmo módulo-23
NIE: Empieza por X, Y o Z, luego sigue el algoritmo del NIF con sustitución
CIF: Letra + 7 dígitos + carácter de control (puede ser letra o dígito según el tipo de entidad)
IBAN: ES + 2 dígitos de control + BBAN de 20 dígitos, validado con MOD-97

La mayoría de implementaciones que encontrarás online tienen bugs sutiles — validación incorrecta de la letra del CIF, casos especiales del NIE que no se contemplan, o errores en el dígito de control del IBAN. Equivocarse significa aceptar identificadores inválidos o rechazar identificadores válidos.

Una alternativa más sencilla: usar una API

Valix es una API REST que valida identificadores fiscales españoles usando los algoritmos oficiales. Gestiona NIF, NIE, CIF e IBAN, detecta el tipo automáticamente y devuelve una respuesta JSON estructurada.

Puedes probarla gratis — sin registro ni API key para el endpoint de prueba.

Primeros pasos

Solo necesitas requests:

pip install requests

Trial: Valida sin registro

El endpoint trial permite hasta 5 identificadores por llamada y 50 validaciones diarias por IP — sin API key.

import requests

def validar_identificadores_trial(identificadores: list[str]) -> dict:
    """
    Valida identificadores fiscales españoles con el endpoint trial de Valix.
    Sin API key. Máximo 5 identificadores por llamada, 50/día por IP.
    """
    url = "https://api.getvalix.io/v1/validate/trial"
    payload = {
        "items": [
            {"value": identificador, "type": "AUTO"}
            for identificador in identificadores
        ]
    }
    response = requests.post(url, json=payload)
    response.raise_for_status()
    return response.json()

# Ejemplo de uso
identificadores = [
    "12345678Z",               # NIF
    "X1234567L",               # NIE
    "A12345674",               # CIF
    "ES9121000418450200051332" # IBAN
]

resultado = validar_identificadores_trial(identificadores[:5])
for item in resultado["results"]:
    estado = "✓ válido" if item["valid"] else "✗ inválido"
    print(f"{item['value']} → {item['detected_type']} {estado}")

Salida:

12345678Z → NIF ✓ válido
X1234567L → NIE ✓ válido
A12345674 → CIF ✓ válido
ES9121000418450200051332 → IBAN ✓ válido

Producción: Validación batch con API key

Para uso en producción, el endpoint batch soporta hasta 100 identificadores por llamada. Obtén tu API key en getvalix.io.

import requests
import os

def validar_batch(identificadores: list[str], api_key: str) -> dict:
    """
    Valida hasta 100 identificadores fiscales españoles en una sola llamada.
    Requiere API key de getvalix.io.
    """
    url = "https://api.getvalix.io/v1/validate/batch"
    headers = {
        "x-api-key": api_key,
        "Content-Type": "application/json"
    }
    payload = {
        "items": [
            {"value": identificador, "type": "AUTO"}
            for identificador in identificadores
        ]
    }
    response = requests.post(url, headers=headers, json=payload)
    response.raise_for_status()
    return response.json()

# Carga la API key desde variable de entorno (nunca la hardcodees)
api_key = os.environ.get("VALIX_API_KEY")

identificadores = [
    "12345678Z",
    "X1234567L",
    "A12345674",
    "ES9121000418450200051332",
    "99999999R",  # NIF inválido
]

resultado = validar_batch(identificadores, api_key)
print(f"Total: {resultado['total']}")
print(f"Válidos: {resultado['valid_count']}")
print(f"Inválidos: {resultado['invalid_count']}")
print()
for item in resultado["results"]:
    if item["valid"]:
        print(f"✓ {item['value']} → {item['detected_type']}")
    else:
        print(f"✗ {item['value']} → {', '.join(item['errors'])}")

Salida:

Total: 5
Válidos: 4
Inválidos: 1

✓ 12345678Z → NIF
✓ X1234567L → NIE
✓ A12345674 → CIF
✓ ES9121000418450200051332 → IBAN
✗ 99999999R → Formato inválido

Estructura de la respuesta

Cada resultado incluye:

{
  "index": 0,
  "value": "12345678Z",
  "requested_type": "AUTO",
  "detected_type": "NIF",
  "valid": true,
  "formatted": "12345678Z",
  "errors": []
}

detected_type: el tipo de identificador detectado (NIF, NIE, CIF, IBAN)
valid: resultado booleano
formatted: versión normalizada del identificador
errors: lista de mensajes de error si es inválido

Para CIF, la respuesta incluye además entity_type con el tipo de entidad mercantil (por ejemplo "Sociedad Anónima").

Gestión de errores

import requests
from requests.exceptions import HTTPError

def validar_con_manejo_errores(identificadores: list[str], api_key: str) -> dict | None:
    try:
        return validar_batch(identificadores, api_key)
    except HTTPError as e:
        if e.response.status_code == 401:
            print("API key inválida o ausente")
        elif e.response.status_code == 429:
            print("Límite mensual de validaciones alcanzado")
        elif e.response.status_code == 400:
            error_data = e.response.json()
            print(f"Petición incorrecta: {error_data.get('error')}")
        else:
            print(f"Error de API: {e}")
        return None

Validación por tipo específico

Si ya conoces el tipo de identificador, puedes pasarlo explícitamente en lugar de usar AUTO:

payload = {
    "items": [
        {"value": "12345678Z", "type": "NIF"},
        {"value": "X1234567L", "type": "NIE"},
        {"value": "A12345674", "type": "CIF"},
        {"value": "ES9121000418450200051332", "type": "IBAN"}
    ]
}

Útil cuando tu fuente de datos ya proporciona el tipo, o cuando quieres forzar la validación de un tipo concreto.

¿Usas JavaScript en lugar de Python?

Valix tiene un SDK oficial para JavaScript/TypeScript disponible como paquete npm:

npm install @valix/sdk

→ Paquete npm @valix/sdk
→ Repositorio del SDK JS

Ejemplos de código

Puedes encontrar ejemplos completos de uso de la API en distintos lenguajes (Python, JavaScript, PHP, cURL) en el repositorio de ejemplos oficial:

→ github.com/getvalix/valix-examples

Precios

Plan	Precio	Validaciones/mes
Trial	Gratis	50/día, sin registro
Starter	€19/mes	10.000
Growth	€49/mes	100.000
Pro	€149/mes	1.000.000

Resumen

Validar correctamente los identificadores fiscales españoles requiere implementar múltiples algoritmos complejos con casos especiales difíciles de contemplar. Usar Valix te da:

Validación precisa basada en algoritmos oficiales
Detección automática del tipo de identificador
Procesamiento batch de hasta 100 identificadores por llamada
Trial gratuito sin registro

Pruébalo en getvalix.io — el endpoint trial no requiere registro.

Cómo construí un SaaS que envía informes de Stripe escritos por IA cada lunes — y lo que aprendí

A. Garrido Builds — Mon, 30 Mar 2026 15:10:24 +0000

Llevo unos meses construyendo Autoreport mientras trabajo a jornada completa. La idea era sencilla: cada lunes por la mañana, recibir un PDF en el inbox con los números de Stripe de la semana anterior — sin dashboards, sin trabajo manual. Así lo construí, el stack que elegí y las lecciones que aprendí.

El problema

Cada lunes abría Stripe para revisar la semana anterior. Revenue, pagos, nuevos clientes. No era difícil — solo generaba fricción. Y como requería esfuerzo, me lo saltaba o lo hacía mal.

Quería que los números vinieran a mí, no al revés.

El stack

Todo el backend corre en AWS, desplegado con Terraform:

Lambda (Python) — una función por etapa del pipeline: extracción de datos, generación de narrativa con IA, construcción del PDF, envío por email
EventBridge — dispara el pipeline cada lunes por la mañana
S3 — almacena los datos brutos de Stripe y los informes generados
DynamoDB — registro de tenants
SES — envío de emails
Secrets Manager — guarda la API key de Stripe de cada cliente
Bedrock (Claude Haiku) — genera la narrativa de IA a partir de las métricas semanales
API Gateway + Lambda — gestiona los webhooks de Paddle para la gestión de suscripciones

La landing page es un sitio estático en Netlify. Los pagos van a través de Paddle como Merchant of Record.

Cómo funciona

El cliente se suscribe a través del checkout de Paddle
Un email automático vía SES incluye un enlace directo de configuración
El cliente pega su Stripe restricted key en un formulario web — se valida contra Stripe en tiempo real y la cuenta se activa automáticamente
Cada lunes, EventBridge dispara el pipeline por tenant
Lambda extrae los datos de Stripe, los envía a Bedrock, construye el PDF y lo entrega vía SES

Lo que me sorprendió

El prompt engineering en Bedrock me llevó más tiempo del esperado. La primera versión de la narrativa era alarmista — "preocupación crítica", "atención inmediata" — ante fluctuaciones semana a semana completamente normales. Tuve que ser muy explícito en el prompt sobre el tono, el contexto y cuándo usar lenguaje contundente de verdad.

Lo que funcionó fue estructurar el prompt en torno a tres cosas: (1) indicarle explícitamente qué métricas importan más y en qué orden, (2) darle umbrales para saber cuándo algo merece ser destacado frente a varianza normal, y (3) decirle qué NO decir — cosas como "requiere atención inmediata" a menos que la tasa de éxito caiga por debajo de un umbral definido o haya varias disputas abiertas.

La restricción más útil fue pedirle que reconociera las bajadas semana a semana de forma neutra y sin alarma, y que centrara la narrativa en lo que muestran los datos, no en lo que podrían significar. Al principio inventaba razones para las bajadas — "esto podría indicar fluctuación estacional o menor inversión en marketing" — que es puro ruido cuando tienes 2 transacciones.

La ruta de Merchant of Record (Paddle) fue la decisión correcta para evitar los dolores de cabeza de impuestos e IVA como fundador en solitario en España. El proceso de aprobación tardó unos días pero mereció la pena.

Qué viene después

Ahora mismo está en beta. Si tienes un SaaS en Stripe y quieres que te llegue tu semana resumida cada lunes sin hacer nada, pruébalo en autoreport.dev.

Encantado de responder cualquier pregunta sobre la arquitectura o el proceso de construcción.

How I built a SaaS that sends AI-written Stripe reports every Monday — and what I learned

A. Garrido Builds — Fri, 27 Mar 2026 06:47:34 +0000

I've been building Autoreport for the past few months alongside my day job. The idea was simple: every Monday morning, get a PDF in your inbox with your Stripe numbers from the previous week — no dashboards, no manual work.

Here's how I built it, the stack I chose, and the lessons I learned along the way.

The problem

I kept opening Stripe every Monday to check the previous week. Revenue, payments, new customers. It wasn't hard — just friction. And because it required effort, I kept skipping it or doing it badly.

I wanted the numbers to come to me, not the other way around.

The stack

The entire backend runs on AWS, deployed with Terraform:

Lambda (Python) — one function per stage of the pipeline: data extraction, AI narrative generation, PDF building, email delivery
EventBridge — triggers the pipeline every Monday morning
S3 — stores raw Stripe data and generated reports
DynamoDB — tenant registry
SES — email delivery
Secrets Manager — stores each customer's Stripe API key
Bedrock (Claude Haiku) — generates the AI narrative from the weekly metrics
API Gateway + Lambda — handles Paddle webhooks for subscription management

The landing page is a static site on Netlify. Payments go through Paddle as Merchant of Record.

How it works

Customer subscribes via Paddle checkout
Automated email via SES includes a direct setup link
Customer pastes their Stripe restricted key in a web form — validated against Stripe in real time, account activates automatically
Every Monday, EventBridge triggers the pipeline per tenant
Lambda pulls Stripe data, sends it to Bedrock, builds a PDF, delivers it via SES

What surprised me

Bedrock prompt engineering took longer than expected. The first version of the AI narrative was alarmist — "critical concern", "immediate attention" — for perfectly normal week-over-week fluctuations. I had to be very explicit in the prompt about tone, context, and when strong language is actually warranted.

The Merchant of Record route (Paddle) was the right call for avoiding tax and VAT headaches as a solo founder in Spain. The approval process took a few days but was worth it.

What's next

Right now it's in beta. If you run a SaaS on Stripe and want your week summarized every Monday without lifting a finger, give it a try at autoreport.dev.

Happy to answer any questions about the architecture or the build process.

Originally published on my personal blog