Personalizar Odoo: Studio en SaaS u Odoo.sh
Hasta dónde se puede adaptar Odoo sin salir de la nube estándar, y en qué momento un proyecto necesita realmente Odoo.sh. Con Studio se resuelve más de lo que la mayoría cree.
En SaaS, Odoo Studio ya permite personalizar bastante: campos, vistas, automatizaciones y reportes. Odoo.sh se necesita sólo cuando hay que tocar código o el núcleo de un módulo como el punto de venta.
La pregunta correcta no es «¿abierto o cerrado?», sino ¿hasta dónde llega Studio para este caso?
Los tres niveles
SaaS estándar
- Odoo tal como viene, configurado a la operación.
- Arranque rápido, infraestructura más barata.
- Respaldos y mantenimiento a cargo de Odoo.
Studio
- Campos y vistas a la medida sin tocar el servidor.
- Automatizaciones y reglas de negocio.
- Reportes QWeb personalizados.
- Se implementa con acceso temporal, sin instalar módulos.
Odoo.sh
- Módulos a la medida y código propio.
- Modificar el core del PDV u otros módulos.
- Conectores con terceros y pipelines Git.
- Ambientes de prueba antes de producción.
Qué resuelve cada camino
| Necesidad | SaaS + Studio | Odoo.sh |
|---|---|---|
| Campos, vistas y flujos personalizados | Sí | Sí |
| Automatizaciones y reglas de negocio | Sí | Sí |
| Reportes a la medida (QWeb) | Sí | Sí |
| Módulos instalables y código propio | No | Sí |
| Modificar el código del punto de venta | No | Sí |
| Conectores con terceros a nivel código | Limitado | Amplio |
Dónde está la frontera real
Studio cubre casi toda la personalización funcional sin salir de SaaS. El límite aparece cuando hay que instalar un módulo, escribir código o modificar el núcleo de una app —el caso típico es cambiar el comportamiento interno del punto de venta—. Ahí, y sólo ahí, el proyecto necesita Odoo.sh.
El costo de los usuarios de Odoo es idéntico en los dos caminos: la diferencia está en la infraestructura y en el nivel de desarrollo, no en las licencias.
Costos recurrentes propios de Odoo.sh
Tres conceptos que en la nube estándar simplemente no se facturan.
Workers
Los procesos que atienden a los usuarios. Se pagan por worker al mes y Odoo sugiere dimensionar alrededor de uno por cada 25 usuarios.
Almacenamiento
El disco de la instancia, sin GB incluidos de arranque. Cuentan la base de datos y los respaldos, y se cobra por GB al mes.
Ambientes de prueba
Cada staging branch que se mantenga activo se cobra al mes. Es justo lo que permite probar un cambio antes de que toque producción.
No copiamos importes aquí a propósito: las tarifas cambian y el monto final depende del dimensionamiento. Las vigentes están en odoo.sh. En SaaS ninguno de estos tres conceptos existe — la nube estándar no se factura por workers, GB ni ambientes de prueba.
Ver tarifas en odoo.shCómo elegir
Basta SaaS + Studio cuando…
- La adaptación es de campos, vistas, flujos o reportes.
- Se quieren automatizaciones sobre apps estándar.
- Se prioriza arrancar rápido y al menor costo.
Se necesita Odoo.sh cuando…
- Habrá módulos a la medida o código propio.
- Se modificará el comportamiento interno del PDV.
- Se integran terceros a nivel código o marketplaces.
¿En cuál de los dos cae tu caso?
Cuéntanos qué necesitas adaptar y te decimos si se resuelve con Studio o si hay que subir a Odoo.sh, aunque la respuesta sea la más barata para ti.