La pregunta "¿no se puede construir esto internamente?" aparece en toda conversación con tech leads. La respuesta honesta: depende de lo que aprobación significa para tu negocio — producto central, requisito regulatorio de aislamiento o simplemente otra feature en el roadmap.
Cuándo construir tiene sentido
1. La aprobación es el producto. Plataformas de governance o compliance cuya diferenciación es el propio flujo de aprobación necesitan controlar el motor en profundidad. Infraestructura externa complementa, pero no sustituye el core.
2. Un único flujo trivial y estable. Ej.: "todo PR necesita un review en GitHub". Esto cabe en decenas de líneas; no justifica integración externa.
3. Los datos no pueden salir del perímetro. Sectores con restricción rígida de egress pueden exigir deploy on-premises. Apruvly ofrece opción enterprise en esa línea (ver docs/onprem-shield.md), pero construir interno sigue siendo válido cuando la política es "cero dependencia de proveedor cloud".
4. Equipo y roadmap de largo plazo para producto interno. Construir no termina en el MVP: mantenimiento de integraciones, edge cases de concurrencia y soporte interno duran años.
Si dos o más de estos puntos se aplican fuertemente, construir puede ser la decisión correcta.
Cuándo construir se convierte en trampa de alcance
Síntomas frecuentes:
- La aprobación es feature del producto, no el producto entero.
- El roadmap ya tiene decenas de ítems que te diferencian en el mercado.
- Ingeniería estima "dos a tres semanas" para el motor completo.
En la práctica, la v1 suele subestimar:
| Componente | Estimación optimista | Esfuerzo realista (orden de magnitud) |
|---|---|---|
| CRUD + estados | días | ~1 semana |
| E-mail con templates | días | ~1 semana |
| Slack (OAuth + bot + interacción) | días | ~2 semanas |
| Escalación por timeout | días | ~1 semana |
| Webhooks con retry y SSRF | días | ~1 semana |
| Multi-cuenta + permisos | días | ~2 semanas |
| Idempotencia / race / double-click | día | ~1–2 semanas |
| UI o designer | semana | semanas a meses |
| WhatsApp / Teams / SMS / … | "después" | semanas por canal |
Total realista para una v1 utilizable: meses, no semanas — antes del mantenimiento continuo.
Dónde Apruvly compite bien
1. Tiempo hasta la primera aprobación real
Una llamada POST /api/v1/workflow/ con config JSON válida coloca notificaciones, enlaces de decisión y trazabilidad en producción el mismo día — versus scaffolding de semanas in-house.
2. Multi-canal sin N integraciones paralelas
Canales soportados como steps: email, slack, ms-teams, whatsapp, twilio-whatsapp, twilio-sms, telegram, discord, dingtalk. Cada uno exige OAuth, templates, rate limits y retries propios si se construye desde cero.
Gates por plan (resumen):
- Twilio (SMS/WhatsApp): Starter+
- Webhook del integrador en la API key: Starter+
- MCP para agentes: Growth+ ($59/mes)
- SMTP propio: Business+ ($149/mes)
- Export consolidado de auditoría: Business+
3. Trazabilidad para compliance
Cada workflow tiene ID; cada aprobador recibe challenge UUID; decisiones registran timestamp, aprobador, comentario y, según el plan, IP y user-agent. Export ZIP asíncrono en Business y Professional (/security/audit-export).
4. Concurrencia e idempotencia
Transiciones persistidas en Postgres con SELECT FOR UPDATE; segundo clic en el mismo challenge es rechazado; replay de enlace antiguo no duplica decisión.
5. Costo predecible
Modelo de créditos: 1 por destinatario notificado (detalles en docs/pricing.md). Sin sorpresa de "broadcast de 10 mil destinatarios" si modelas el UnitCost antes de crear el workflow.
Dónde construir in-house aún gana
- Reglas con lookup profundo en tu base de datos en el momento de la decisión, sin pasar contexto vía API.
- Latencia extrema dentro del mismo proceso (raro en aprobación humana).
- Política de zero egress sin flexibilidad para on-prem gestionado.
- Motor ya existente y estable — migrar por moda rara vez compensa.
Dependencia de proveedor
Apruvly expone API REST estable; status y decisiones son consultables y exportables; webhooks de retorno son HTTP estándar. Cambiar de proveedor exige trabajo — como con Stripe, SendGrid o cualquier SaaS de infraestructura. La alternativa in-house intercambia dependencia de vendor por dependencia del equipo que mantiene el código.
Ejercicio de decisión (30 minutos)
- Lista los cinco flujos de aprobación necesarios en los próximos 12 meses.
- Para cada uno: canales, escalación, trazabilidad auditable, aprobador externo sin login.
- Estima esfuerzo de eng para entregar y mantener.
- Compara con Growth ($59/mes, 40k créditos, MCP) o Business ($149/mes, export de auditoría, SMTP propio).
- Suma el costo de retrasar features que diferencian tu producto en el mercado.
Si la cuenta cierra para construir, construye. Si no, infraestructura lista libera al equipo para lo que solo tu producto hace.
Probar antes de decidir
Plan Free: 180 créditos/mes, sin tarjeta. Ejecuta un workflow real de tu dominio y compara con el alcance que estimaron internamente.
apruvly.io