Saltar al contenido principal
Oikapp
Volver al blog

3 min de lecturaOikapp

Lo que validamos construyendo Oikapp antes del primer cliente

Decisiones tomadas durante el desarrollo: que partes del producto resultaron mas faciles de lo esperado, que partes mas dificiles, y que cambiamos del plan original.

En el papel, Oikapp era una idea redonda: SaaS multi-tenant, IA + RAG, pagos LATAM y EU, BYO WhatsApp. En la fase de construccion y prototipado algunas cosas resultaron mas faciles de lo esperado, otras mas dificiles. Esta es la lista honesta de las decisiones que tomamos antes del primer cliente pagador.

Lo que resulto mas facil de lo esperado

1. La conexion BYO de WhatsApp es mas simple de lo que pensabamos

Esperabamos que el flujo Meta de Tech Provider fuera una pesadilla burocratica. Al construirlo y probarlo, los 4 fields requeridos (App ID, App Secret, Phone Number ID, WABA ID) toman 30-45 min para un usuario promedio. Empiezas a usarlo el mismo dia.

2. RAG sobre PDF resulto practico desde el dia 1

Pensabamos que RAG era un feature avanzado que pocos usarian al inicio. En las pruebas con casos reales (FAQs, tarifas y politicas en PDF), el chunking de 512 tokens con 50 de overlap fue suficiente para retrieval util en la mayoria de preguntas tipicas de servicio.

3. La curva del Flow Builder con plantilla es <2 horas

Probando con personas sin background tecnico, una plantilla pre-construida se podia adaptar a un negocio en menos de 2 horas. Sin plantilla, el onboarding se duplicaba.

Lo que resulto mas dificil de lo esperado

4. El bloque Pago necesita un mensaje previo de confianza

En pruebas, los usuarios finales abandonaban en el bloque Pago porque "el link en WhatsApp no se ve seguro". Solucion: agregar un Mensaje pre-pago que explica "vas a recibir un link seguro de Wompi/Stripe — recibes recibo digital al pagar". Quedo como recomendacion estandar en las plantillas.

5. La base de conocimiento se desactualiza rapido

Los PDFs subidos al KB tienen tendencia a desactualizarse (cambia un precio, cambia una politica). Sin un workflow de "fecha de actualizacion" + alertas, el agente IA empieza a dar info desactualizada. Solucion en plan: alerta de "tu KB no se actualiza desde X dias".

6. Los WhatsApp templates de Meta son confusos

Despues de 24h sin interaccion, Meta exige usar templates pre-aprobados. La diferencia entre "free conversation" y "template message" no es intuitiva. Escribimos guia detallada (esta en /help/configurar-whatsapp-byo).

Lo que cambiamos del plan original

7. Adelantamos el bloque Condicion

Originalmente iba a llegar mas adelante. Cuando construimos las plantillas verticales (consultorio, restaurante, salon) descubrimos que casi todas requerian bifurcar el flujo segun la opcion del usuario. Sin Condicion, el flujo quedaba lineal y aburrido. Decidimos adelantarlo.

8. Modo de prueba antes de gastar creditos en IA real

Para reducir friccion al evaluar la plataforma, agregamos un modo de prueba que responde con texto predefinido. Asi se puede probar el flujo sin gastar creditos. Pasar a IA real (OpenAI/Anthropic) queda como un clic.

9. El portal publico fue mas trabajo del esperado

Un portal de marketing efectivo no es solo "una pagina bonita" — son decenas de paginas (precios, demo, casos, blog, comparativas, preguntas frecuentes, seguridad, estado, documentacion, integraciones, plantillas). Lo subestimamos en la planificacion.

La hipotesis que vamos a verificar con los primeros clientes

10. La adopcion no es tecnica, es psicologica

Nuestra hipotesis: los negocios que mas crecen con un canal automatizado no son los que tienen el mejor flujo tecnico, sino los que confian en el sistema lo suficiente para promocionarlo a sus clientes. Esa confianza viene de: 1) el flujo no fallar en los primeros 50 mensajes, 2) recibir notificacion cuando el saldo baja, 3) sentir que el agente IA "habla bien" el tono del negocio. Construir confianza es el Job to Be Done #1 que vamos a validar con los primeros clientes.

#producto#arquitectura#lecciones
Compartir