Makers3D/docs/Makers3D_Auditoria_MVP.md

Makers3D - Auditoria MVP

1. Dictamen ejecutivo

La propuesta original acierta en la promesa de negocio, pero mezcla un MVP real con capas de producto, UX y arquitectura propias de una fase posterior. La reauditoria reduce el proyecto a una plataforma de descubrimiento y contacto profesional para makers 3D en Argentina, manteniendo el negocio principal:

• descubrir makers por zona, especialidad y capacidad;
• mostrar portfolio real y servicios;
• iniciar contacto dentro de la plataforma;
• permitir seguimiento basico de la conversacion;
• cobrar al maker por aparecer publicamente.

Se elimina o difiere todo lo que no acelera esas cinco promesas.

2. Decisiones de recorte

Se conserva como nucleo

• mapa, lista, busqueda y filtros;
• perfil publico del maker;
• trabajos publicados;
• servicios publicados;
• cuenta unica para cliente y maker;
• alta de maker en borrador;
• publicacion condicionada a calidad minima y suscripcion activa;
• contacto guiado;
• bandeja de mensajes;
• resena verificada tras relacion completada;
• moderacion y backoffice basicos;
• un unico plan de pago.

Se difiere

• favoritos;
• comparacion entre makers;
• escaparates tematicos;
• multiples ubicaciones por maker;
• dashboard avanzado y analitica de negocio;
• PWA instalable completa;
• notificaciones push;
• patrocinio y publicidad;
• SEO programatico avanzado;
• permisos granulares internos;
• telemetria avanzada;
• automatizaciones comerciales.

Se elimina del MVP

• marketplace;
• checkout cliente-maker;
• apps nativas;
• gamificacion;
• likes, comentarios y senales sociales publicas;
• reputacion externa no verificable;
• microservicios;
• orquestacion compleja;
• motores de busqueda externos;
• tiempo real por WebSockets;
• stack de observabilidad pesada desde el dia uno.

3. Clasificacion funcional

Componente	Clasificacion	Decision
Descubrimiento en mapa y lista	OBLIGATORIO	Es la promesa central del producto.
Busqueda textual y filtros por servicio, tecnologia, material, distancia y envio	OBLIGATORIO	Sin esto el mapa es solo decoracion.
Perfil publico del maker	OBLIGATORIO	Convierte descubrimiento en confianza.
Trabajos publicados con fotos	OBLIGATORIO	La prueba principal de calidad del maker.
Servicios publicados	OBLIGATORIO	Permiten explicar que ofrece cada maker.
Cuenta unica cliente-maker	OBLIGATORIO	Reduce friccion y soporte.
Perfil maker en borrador privado	OBLIGATORIO	Permite preparar la oferta antes de pagar.
Publicacion condicionada a minimos de calidad	OBLIGATORIO	Evita mapa vacio o basura pagada.
Suscripcion unica para aparicion publica	OBLIGATORIO	Es el modelo de ingresos inicial.
Contacto guiado	OBLIGATORIO	Convierte visitas en consultas utiles.
Mensajeria interna basica	OBLIGATORIO	Da trazabilidad y permite resenas verificadas.
Resena verificada tras trabajo completado	OBLIGATORIO	La reputacion debe nacer de relaciones reales.
Moderacion y backoffice basicos	OBLIGATORIO	Sin esto no hay confianza operable.
Geolocalizacion del navegador	RECOMENDADO	Mejora la apertura, pero debe existir alternativa manual.
SEO basico de perfil y trabajo	RECOMENDADO	Aporta captacion sin rehacer producto.
Emails transaccionales	RECOMENDADO	Necesarios para verificacion y eventos criticos.
Favoritos	FASE 2	Util, pero no cambia la propuesta inicial.
Comparacion entre makers	FASE 2	Valiosa, pero prescindible para abrir beta.
Escaparates tematicos	FASE 2	Son una mejora editorial, no una necesidad comercial.
Multiples ubicaciones por maker	FASE 2	Añade complejidad operativa y geoespacial.
Dashboard con embudos y estadisticas avanzadas	FASE 2	Conviene medir primero antes de sofisticar.
Notificaciones internas ricas y push	FASE 2	La combinacion email + badge es suficiente al inicio.
SEO programatico por provincias y categorias	FASE 2	Requiere oferta real y control editorial.
Programa de makers fundadores automatizado	FASE 2	Puede operarse manualmente en beta.
Publicidad sectorial y patrocinio	FASE 3	Solo cuando exista volumen y reglas maduras.
Comunidad, cursos, eventos y contenido social	FASE 3	Son negocios distintos.
App nativa iOS/Android	FASE 3	No acelera validacion inicial.
Marketplace completo	ELIMINAR	Cambia el negocio y multiplica riesgo legal y tecnico.
Gamificacion	ELIMINAR	No resuelve el problema principal.
Likes y comentarios publicos	ELIMINAR	Introducen ruido y falsos signos de calidad.
Reseñas externas no verificadas	ELIMINAR	Complican confianza y moderacion sin suficiente valor.

4. Clasificacion tecnica

Componente	Clasificacion	Decision
API REST monolitica modular	OBLIGATORIO	Mas barata y mas facil de operar que microservicios.
Next.js para web responsive	OBLIGATORIO	Resuelve publico, cuenta, area maker y admin en una sola app.
NestJS para API	OBLIGATORIO	Ordena dominio, auth y pagos sin inventar estructura.
PostgreSQL	OBLIGATORIO	Fuente canonica unica para negocio, mensajes y pagos.
PostGIS	OBLIGATORIO	El mapa y la distancia son parte del producto, no un adorno.
FTS + pg_trgm en PostgreSQL	OBLIGATORIO	Cubre busqueda inicial sin otro motor.
Docker	OBLIGATORIO	Simplifica desarrollo, staging y despliegue.
Docker Compose	OBLIGATORIO	Suficiente para MVP autoalojado.
Nginx como proxy y servidor de activos	OBLIGATORIO	Una sola pieza perimetral basta para empezar.
Storage S3-compatible	OBLIGATORIO	Evita acoplar archivos al contenedor.
MinIO	OBLIGATORIO	Opcion self-hosted simple para almacenamiento inicial.
Worker unico para tareas asincronas	OBLIGATORIO	Necesario para email, imagenes y webhooks.
Polling controlado para mensajeria	OBLIGATORIO	Mucho mas simple que tiempo real completo.
Logs estructurados	OBLIGATORIO	Base minima de soporte y auditoria.
Backups de base de datos y objetos	OBLIGATORIO	Sin esto no debe abrirse beta.
Seguridad base: Argon2id, cookies seguras, CSRF, rate limiting, URLs firmadas	OBLIGATORIO	Minimo para usuarios y cobros reales.
Autenticacion por email y contraseña	OBLIGATORIO	Camino mas directo y entendible.
Autorizacion por roles fijos	OBLIGATORIO	Guest, user, maker y admin cubren el MVP.
Mercado Pago	OBLIGATORIO	Solucion inicial mas pragmatica para cobrar en Argentina.
CI minimo con tests y build	OBLIGATORIO	Reduce roturas al trabajar con humanos e IA.
Geolocalizacion del navegador	RECOMENDADO	Buen atajo UX, nunca obligatoria.
Email transaccional externo	RECOMENDADO	Ahorra mucho riesgo de entregabilidad.
MapLibre + PMTiles	RECOMENDADO	Mantiene control de costes y evita dependencia temprana de terceros.
Observabilidad minima de salud y errores	RECOMENDADO	Suficiente para beta cerrada.
Redis	FASE 2	Solo si el trafico o el rate limiting lo exigen.
BullMQ	FASE 2	Solo si PostgreSQL deja de ser suficiente para colas.
CDN	FASE 2	No hace falta antes de comprobar volumen y geografia real.
Cloudflare	FASE 2	Puede ayudar despues, no debe condicionar el arranque.
SSE para actualizacion de bandeja	FASE 2	Mejora UX sin ser requisito inicial.
Scheduler separado	FASE 2	El worker puede asumir tareas programadas al principio.
Observabilidad con paneles y alertas avanzadas	FASE 2	Conveniente tras la beta interna.
Grafana	FASE 3	Util cuando haya mas servicios y alertas formales.
Prometheus	FASE 3	No justifica su coste operativo al inicio.
Loki	FASE 3	Los logs estructurados bastan en MVP.
Tempo	FASE 3	Trazas distribuidas sin sistema distribuido no son prioridad.
Traefik	ELIMINAR	Duplica funciones cubiertas por Nginx.
RabbitMQ	ELIMINAR	Sobreingenieria para el volumen esperado.
Kafka	ELIMINAR	Totalmente fuera de escala para el MVP.
Elasticsearch	ELIMINAR	PostgreSQL cubre el problema inicial.
OpenSearch	ELIMINAR	Mismo motivo que Elasticsearch.
Kubernetes	ELIMINAR	Añade operacion sin aportar valor temprano.
WebSockets	ELIMINAR	La mensajeria puede nacer con polling.
Prisma	ELIMINAR	Penaliza flexibilidad SQL y PostGIS; no simplifica el nucleo.
Microservicios	ELIMINAR	Mas coste, mas despliegue, mas mantenimiento.

5. Reglas de simplificacion aprobadas

1. Un maker tendra una sola ubicacion operativa en el MVP.
2. Un maker publicara al menos un servicio y un trabajo con foto.
3. La suscripcion habilita la posibilidad de publicar, pero no publica por si sola.
4. Las resenas validas nacen de una relacion completada en la plataforma.
5. Los archivos del MVP se limitan a imagenes y PDF. No habra STL, ZIP o 3MF publicos.
6. El mapa es importante, pero toda accion critica debe tener alternativa en lista.
7. El backoffice sera austero: cola de revision, ficha de maker, pagos, casos y auditoria.
8. Toda capacidad futura solo entra si mejora conversion, confianza o coste operativo.

6. Forma final del MVP

Makers3D debe salir como:

• una web responsive;
• con mapa y lista;
• con makers publicos de pago;
• con portfolios visuales simples;
• con contacto guiado;
• con seguimiento basico de mensajes;
• con reputacion nacida de trabajos reales;
• y con operacion interna suficiente para moderar, cobrar y responder incidencias.

Todo lo demas debe esperar a que exista uso real.