Monco Tattoo
Plataforma para un estudio de tatuajes que reemplazó la recepción de solicitudes por Instagram y WhatsApp: portafolio, formulario de citas guiado y un panel donde el artista revisa cada caso.
- Estado
- En producción
- Tipo
- Cliente
- Desde
- marzo de 2026
- Mi rol
- Desarrollo integral: diseño de interfaz, frontend, backend, base de datos y despliegue.
- Stack
- Next.jsTypeScriptTailwind CSSPrismaPostgreSQL (Neon)NextAuthCloudinaryResendVercel
Problemas y cómo los resolví
- 01
ProblemaEl artista recibía las solicitudes por Instagram y WhatsApp, incompletas y sin orden, y debía hacer las mismas preguntas a cada cliente.
SoluciónConvertí esas preguntas en un formulario por pasos (idea, estilo, zona del cuerpo, tamaño, disponibilidad y fotos de referencia), validado con Zod. Cada solicitud llega al panel como un caso completo.
- 02
ProblemaDurante una revisión del código detecté que la edición de citas aceptaba cualquier campo enviado y que la búsqueda por WhatsApp exponía el ticket de la cita. En conjunto, permitían que un tercero aprobara una cita ajena.
SoluciónImplementé una lista blanca con Zod en cada endpoint, exigí ticket y WhatsApp a los usuarios invitados y dejé de devolver campos internos. Lo verifiqué con 26 pruebas HTTP: 16 fallaban contra la versión anterior.
- 03
ProblemaEl artista no se enteraba a tiempo de las nuevas solicitudes.
SoluciónCada solicitud genera una notificación por correo con Resend. El servicio solo se inicializa si existe una clave configurada, para que la compilación no falle si falta.
- 04
ProblemaMuchos clientes no querían crear una cuenta, pero sí necesitaban conocer el estado de su solicitud.
SoluciónCada solicitud genera un ticket. Con él y su WhatsApp o documento, el cliente consulta y edita su cita sin registrarse. Si el ticket no existe o el dato no coincide, la respuesta es idéntica, para no revelar qué tickets son válidos.
- 05
ProblemaLa primera versión guardaba citas y perfiles en un archivo JSON local, una solución que no escala en producción.
SoluciónMigré los datos a PostgreSQL en Neon con Prisma, con el adaptador serverless para garantizar un buen funcionamiento en Vercel.
- 06
ProblemaLos clientes necesitaban subir hasta cinco fotos de referencia sin exponer las credenciales de Cloudinary.
SoluciónEl servidor firma cada carga y el navegador envía la imagen directamente a Cloudinary. La clave secreta nunca sale del servidor y el backend no procesa archivos pesados.
- 07
ProblemaCuando un cliente modificaba su solicitud, el artista no sabía qué había cambiado.
SoluciónCada modificación genera un registro de cambios en el servidor, no en el cliente, que el artista consulta en el ticket.
- 08
ProblemaAl actualizar a Prisma 7, la validación del esquema falló (P1012): la URL de conexión ya no se admite en schema.prisma.
SoluciónTrasladé la conexión a prisma.config.ts y cargué las variables de entorno de forma explícita, ya que Prisma 7 no lee el archivo .env automáticamente.
- 09
ProblemaLas funciones serverless de Vercel abren numerosas conexiones simultáneas a la base de datos.
SoluciónLa aplicación usa la URL con pooling de Neon (PgBouncer) y las migraciones, una conexión directa, cada una con su propia variable de entorno.
- 10
ProblemaEn producción, NextAuth no contaba con una clave para firmar las cookies de sesión.
SoluciónDefiní NEXTAUTH_SECRET y lo incluí de forma explícita en la configuración de autenticación.
- 11
ProblemaEn dispositivos móviles, la página de inicio tenía desplazamiento horizontal y el cursor se desalineaba sobre los elementos interactivos en canvas.
SoluciónEliminé las capas de canvas que interferían y corregí los desbordamientos, hasta lograr una página sin desplazamiento lateral y con el cursor alineado.