# 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.