Si necesitas reunir documentación, tareas y contexto de cada proyecto, empezaríamos por Notion. Si lo importante es relacionar clientes, pedidos, responsables y estados, probaríamos Airtable. Un panel a medida entra en la conversación cuando necesitas controlar un proceso que esas herramientas no cubren bien, incluso después de configurarlas.
No son tres peldaños que toda empresa tenga que subir. Puedes crecer con una herramienta estándar, combinarla con una pequeña integración o desarrollar solo una parte. La decisión depende de lo que necesita hacer el equipo con los datos, no de cuánto impresione la pantalla de inicio.
Notion y Airtable se parecen, pero invitan a trabajar de forma distinta
En Notion, una ficha de proyecto puede contener las notas de una reunión, el briefing, archivos, tareas y decisiones. Esa combinación de texto y datos resulta cómoda cuando entender el trabajo importa tanto como saber en qué estado está.
Airtable encaja especialmente bien cuando la operación se puede describir mediante registros relacionados. Un cliente tiene varios pedidos; cada pedido tiene entregas, fechas y responsables. Su diseñador de interfaces permite construir pantallas sobre esos datos para que cada persona consulte o actualice lo que necesita, sin trabajar siempre dentro de una tabla completa.
Como punto de partida, esta sería nuestra elección:
| Necesidad principal | Probaríamos primero | Qué comprobaríamos |
|---|---|---|
| Manuales, documentación y seguimiento de proyectos | Notion | Que encontrar información y mantenerla al día resulte sencillo |
| Clientes, pedidos o incidencias relacionados entre sí | Airtable | Que el modelo de datos cubra también las excepciones |
| Un proceso comercial o de gestión ya habitual | Una herramienta especializada | Que un CRM o un programa del sector no lo resuelva con menos configuración |
| Reglas propias e integraciones que condicionan toda la operación | Un prototipo de la parte específica | Que el problema esté en las capacidades de la herramienta, no en su configuración |
La distinción no significa que Notion sea solo un bloc de notas. Tiene relaciones entre bases de datos y cálculos sobre ellas, además de automatizaciones nativas para crear o modificar páginas, enviar avisos y realizar otras acciones. Algunas funciones dependen del plan y hay restricciones entre disparadores y acciones.
Airtable también dispone de automatizaciones con límites según el plan. No basta con que una función aparezca en la lista: comprueba cuántas veces se ejecutará, quién podrá usarla y qué sucede si falla.
Por ejemplo, para coordinar proyectos con mucho briefing y documentación, probaríamos Notion. Para seguir pedidos con varias entregas parciales, probaríamos Airtable y revisaríamos desde el principio cómo registrar una cancelación o devolución. Es ahí donde una comparación de funciones empieza a convertirse en una decisión útil.
Tener un panel propio no obliga a desarrollar todo desde cero
Antes de encargar una aplicación completa, conviene separar lo que ya funciona de lo que falta. A veces necesitas una pantalla más sencilla para el equipo. Otras, conectar dos sistemas para dejar de introducir el mismo dato dos veces. Ninguna de esas necesidades demuestra por sí sola que haya que abandonar Notion o Airtable.
Ambas herramientas permiten integraciones. Notion ofrece una API para conectar otros sistemas y Airtable combina interfaces, automatizaciones y conexiones externas. Se puede conservar la herramienta y añadir una integración o una interfaz específica, siempre que sus permisos y límites encajen con el uso previsto.
El desarrollo propio merece estudiarse cuando puedes describir la limitación con precisión. Por ejemplo:
- Una operación debe actualizar varios sistemas, detectar un fallo a mitad y permitir recuperarse sin duplicar pedidos.
- Cada usuario necesita un acceso a datos y acciones que la configuración disponible no permite resolver de forma segura.
- El trabajo exige reglas, validaciones o un historial de cambios que resultan difíciles de mantener entre varias herramientas.
- Una prueba con un volumen representativo incumple los tiempos de respuesta o los límites que necesita el negocio.
No hace falta esperar a que algo se rompa en producción para comprobarlo. Pero sí distinguir un requisito necesario de una preferencia. «Necesitamos que el almacén confirme cada entrega parcial» describe un proceso. «Queremos que sea como Airtable, pero nuestro» todavía deja bastante trabajo por definir.
Un caso propio, el Panel SEO que usamos en Nereida
En el estudio desarrollamos un Panel SEO de uso interno. Reúne datos de fuentes como Search Console y los relaciona con tareas sobre una web. La parte específica no es tener una lista de pendientes: eso también podríamos organizarlo en una herramienta estándar.
Lo particular está en el recorrido de determinados cambios. El panel conserva la propuesta, exige aprobación antes de aplicarla en WordPress, guarda el valor anterior y comprueba después lo que se ha escrito. Esas reglas forman parte del programa, además de aparecer en la interfaz. Nos sirven para conectar el diagnóstico con el trabajo SEO mes a mes.
Ese es un ejemplo del tipo de necesidad que puede justificar desarrollo específico: controlar cómo se ejecuta una operación y qué rastro deja. No solo mostrar sus datos. También habría que programar parte de ese comportamiento si la pantalla estuviera montada sobre otra herramienta.
El panel sigue en desarrollo y mantenerlo es trabajo del estudio. Tenerlo no demuestra que una aplicación propia sea más barata que Notion o Airtable, ni que cualquier empresa necesite una. Muestra qué parte de nuestro proceso hemos decidido controlar directamente y de qué mantenimiento nos hacemos cargo.
Compara el trabajo de mantener cada opción, además de la cuota
Las licencias son una parte de la comparación. También cuentan configurar el sistema, limpiar e importar datos, formar al equipo, mantener integraciones y resolver incidencias. Esos costes existen aunque no haya código propio.
En una herramienta por suscripción, revisa qué usuarios o tipos de acceso se facturan y qué plan necesitas realmente. Añade las conexiones externas y la persona que administrará el espacio. El proveedor mantiene la plataforma; alguien de tu equipo sigue siendo responsable de su configuración y uso.
En un desarrollo propio, cuenta diseño, programación, pruebas, alojamiento cuando lo necesite, copias, seguridad, soporte y futuras modificaciones. También puede depender de servicios de pago o componentes con licencia. Incorporar usuarios puede aumentar la carga y las necesidades de soporte, aunque no exista una cuota por asiento.
Por eso no hay un punto universal en el que tres años de suscripciones hagan que desarrollar se amortice automáticamente. Compara el mismo proceso, los mismos usuarios y el mismo nivel de soporte durante un periodo razonable para tu negocio. Si no puedes estimar aún cómo será ese uso, una prueba pequeña aporta más que una previsión a cinco años.
La adopción también cuenta. Haz que pruebe el sistema quien va a usarlo, no solo quien lo configura. Observa si puede completar una tarea habitual, encontrar un dato y corregir un error sin pedir ayuda. Si después vuelve a su hoja de cálculo, pregunta qué paso le resultó más fácil allí antes de atribuirlo a resistencia al cambio.
Comprueba cómo entrarás y cómo podrás salir
Poder exportar datos es importante, pero no equivale a llevarte la aplicación funcionando. Notion permite exportar contenido, aunque sus relaciones no se reconstruyen reimportando un CSV. Airtable permite exportar vistas de tabla a CSV; ese archivo no reproduce por sí solo interfaces y automatizaciones.
Antes de depender del sistema, prueba una exportación representativa. Revisa qué ocurre con los adjuntos, las relaciones entre registros y la información que necesitas conservar. Documenta también las automatizaciones que habría que rehacer en otro sitio.
Un desarrollo a medida no elimina esta dependencia por llevar tu logo. Aclara quién controla las cuentas y el código, cómo se hacen y recuperan las copias y qué necesitaría otra persona para mantenerlo. Si solo sabe arrancarlo quien lo programó, has cambiado de dependencia, no la has eliminado.
Prueba un proceso completo antes de elegir
Escoge un recorrido pequeño, pero realista: entra una solicitud, alguien la revisa, se asigna, cambia de estado y se cierra. Incluye las excepciones habituales y los roles que intervienen. Para la primera prueba puedes usar datos ficticios que reproduzcan esas condiciones, sin cargar información sensible innecesaria.
Comprueba cinco cosas:
- El dato entra una sola vez. Si hay que copiarlo a otro sistema, deja identificado dónde y por qué.
- Cada persona tiene el acceso correcto. Comprueba qué puede ver y modificar entrando con su rol, no desde la cuenta administradora.
- Una excepción tiene salida. Prueba un duplicado, un dato incompleto, una cancelación y una conexión que falla.
- La tarea se completa con comodidad. Incluye el dispositivo desde el que se trabajará, especialmente si es un móvil.
- Alguien puede mantenerlo. Debe quedar claro quién cambia una regla, revisa un fallo y recupera los datos.
Anota qué funciona, qué exige trabajo manual y qué no has podido resolver. Esa lista permite decidir entre seguir con la herramienta, configurarla mejor, añadir una integración o desarrollar una parte. Evita empezar por veinte pantallas: la reunión para decidir sus colores puede esperar.
Si aparece una limitación concreta, en desarrollo a medida podemos valorar qué parte merece construirse y qué conviene conservar. El punto de partida útil es ese proceso probado, con sus dificultades identificadas.