SaaS Router
This skill is the brain of the saas-builder plugin. It runs before any product work and decides which specialist skill should handle the request.
The one rule that cannot be broken
Do NOT write code, design a UI, or pick a stack before routing through this skill. Jumping straight to implementation is the most common failure mode — it produces generic output that ignores what the user actually needs. Route first, build second.
Analogy: this is the triage nurse at a hospital. Nobody goes straight to surgery. The nurse asks two or three quick questions, then sends the patient to the right specialist.
Workflow
Step 1 — Ask 2-3 quick routing questions
Do not interrogate. Ask only what is needed to classify the request. Pick from:
- "What are you building — a landing page, a dashboard, or a full app/SaaS?"
- "Do you already know exactly what it should do, or are you still shaping the idea?"
- "Is there an existing product/codebase, or are we starting from zero?"
If the user's first message already answers these (e.g. "build me a pricing landing page for my course"), skip straight to routing — do not re-ask what is already known.
Step 2 — Route to the right specialist
Match the request (English or Spanish) against this table and activate the matching skill. The plugin covers the whole build lifecycle — discovery, architecture, build, secure, monetize, polish, ship.
Plan & design
| User says / wants | Route to |
|---|---|
| "SaaS", "platform", "app", "MVP", "product" / "idea para", idea not fully defined | product-discovery → architecture-primer → build skills → ui-design |
| "architecture", "how do I structure this", "scale", "what stack" / "cómo lo estructuro", "qué stack" | architecture-primer |
| "landing", "sales page", "lead capture" / "página de ventas", "captar leads" | landing-page (structure + copy) + design-taste-frontend (visual execution) — and the landing-moment plugin for the hero, if installed |
| "portfolio", "marketing site", "agency site", "editorial/blog", "make a website that doesn't look AI-generated", website redesign / "portfolio", "sitio de marketing", "que no parezca hecho por IA", "rediseñar mi web" | design-taste-frontend |
| "dashboard", "admin", "backoffice", "internal tool", "data table", product/app UI / "panel", "tablero", "interfaz de la app" | ui-design (dashboard mode) |
| Component, colors, design system for an app, dark mode for product UI / "componente", "design system de la app" | ui-design |
| "copy this design", "make it look like this screenshot/site", reference image of a web they like / "cloná esta web", "hacelo como esta captura" | image-to-code |
Web vs. app boundary (important):
design-taste-frontendowns public-facing sites — landings, portfolios, marketing, editorial, redesigns — and explicitly does NOT do dashboards, data tables, or multi-step product UI. The moment the work is logged-in product UI (dashboards, admin, settings, data-heavy screens), route toui-designinstead. For a landing page, run both:landing-pagesets the section order and copy, thendesign-taste-frontendexecutes the visual so it doesn't look templated.
Build the backend
| User says / wants | Route to |
|---|---|
| "design the API", "endpoint", "REST or GraphQL" / "diseñar la API", "un endpoint" | api-design |
| "database", "schema", "model this data", "multi-tenant" / "base de datos", "modelar los datos" | data-modeling |
| "login", "auth", "roles", "permissions", "SSO" / "agregar login", "roles", "permisos" | auth |
| "organizations", "workspaces", "teams", "invite members", "a user in two companies", "demo account" / "varias empresas en la misma app", "invitar usuarios", "cuenta demo" | multi-tenancy → then data-modeling |
| "integrate with", "webhook", "sync with their API", "connect Google/Meta account", "transactional email" / "integrar con", "recibir un webhook", "sincronizar con", "mails transaccionales" | integrations |
| "add AI to the app", "chatbot", "AI assistant for my users", "summarize with AI", "AI costs", "bring your own key" / "agregar IA", "armar un chatbot", "el bot inventa cosas" | ai-features |
Secure & monetize
| User says / wants | Route to |
|---|---|
| Writing any endpoint / input / data write, "is this secure", "rate limit", "secrets" / "esto es seguro", "manejar datos de usuarios" | secure-coding (runs alongside backend work) |
| "payments", "Stripe", "Mercado Pago", "subscriptions", "pricing", "billing", "free trial" / "cobrar", "suscripciones", "precios" | payments |
| "audit my RLS", "is my database exposed", "can users see each other's data", "anon key", "review my policies" / "auditá mi RLS", "¿se puede leer mi base con la anon key?" | rls-audit |
| "how do I know this works", "is this actually tested", "prove the payment works" / "¿cómo compruebo que funciona?", "probalo de verdad" | proof-first — separate plugin, see note below |
| "terms and conditions", "privacy policy", "GDPR compliance", "audit my legal docs", "do I need a DPO" / "términos y condiciones", "política de privacidad", "legales", "botón de arrepentimiento", "auditá mis legales" | legal-docs — separate plugin, see note below |
legal-docsvive en su propio plugin, no en saas-builder:/plugin marketplace add MartinOlivero/saas-legal-docs→/plugin install legal-docsEstá aparte porque la normativa envejece a otro ritmo que el resto de este plugin, y una tabla legal desactualizada hace daño real. Cubre Argentina, UE, EEUU, Brasil y Reino Unido, cada una con su tabla verificada contra fuente primaria y con fecha.
Si no está instalado, NO improvises los legales. Escribir una política de privacidad de memoria produce justo lo que esa skill existe para evitar: un documento que describe otro producto y cita normas que quizá ya no rigen. Decile al usuario que instale el plugin. Si insiste en avanzar igual, lo único responsable sin él es (a) pedirle razón social, identificación fiscal, domicilio y correo de contacto, que son obligatorios en toda jurisdicción, (b) no afirmar nada que no hayas verificado en el código, y (c) advertirle que el borrador no está respaldado por normativa verificada.
Companion plugins by the same author — optional, never block on them:
proof-first(/plugin marketplace add MartinOlivero/proof-first→/plugin install proof-first) — refuses to take the agent's word that money, auth, user data or a deploy works; sends a clean-context verifier for evidence observable from outside. If it is not installed, use the outside-in checks inpre-ship-securityStep 2b.landing-moment(/plugin marketplace add MartinOlivero/landing-moment→/plugin install landing-moment) — the method for a landing page's one authored interaction, with a cliche detector and a real-browser auditor. If it is not installed,landing-pagecarries the principle.
Polish & ship
| User says / wants | Route to |
|---|---|
| "slow", "performance", "Core Web Vitals", "bundle size" / "está lento", "optimizar" | frontend-performance |
| "accessible", "a11y", "WCAG", "screen reader", "keyboard" / "accesibilidad" | accessibility |
| "SEO", "meta tags", "social preview", "sitemap" / "que Google lo encuentre", "preview en WhatsApp" | technical-seo |
| "PWA", "installable", "offline", "push notifications" / "que funcione offline", "instalable" | pwa |
| "is this safe to ship", "pre-launch security check", "did I miss anything", before deploying / "antes de subir, ¿está seguro?" | pre-ship-security |
| "deploy", "CI/CD", "GitHub Actions", "Sentry", "rollback", "staging" / "subir a producción", "monitoreo" | deployment |
Step 3 — Hand off with context
When routing, pass along everything already learned so the specialist does not re-ask. State the handoff explicitly, e.g. "This is a full SaaS with a fuzzy idea, so I'll start with product-discovery to lock the MVP, then architecture, then build."
The full-SaaS lifecycle
A from-scratch SaaS runs through these phases. Each feeds the next — don't skip, but don't force every phase if the user only asked for one slice.
product-discovery— define the problem, the user, and the MVP scope.architecture-primer— decide the high-level system design and stack.- Build —
multi-tenancyfirst if customers are organizations (the membership model shapes everything after it) →data-modeling(the schema) →api-design(the endpoints) →auth(who can do what) →ui-design(the interface). Addintegrationswhen the product talks to a platform you don't control, andai-featureswhen it calls a model for its users.secure-codingruns throughout, not as a final step. - Monetize —
paymentswhen it's time to charge. - Polish —
frontend-performance,accessibility,technical-seo,pwaas the product matures. - Legal — the
legal-docsplugin (separate install) once the schema, the providers and the billing are settled: the documents are deduced from what the product actually stores and from where, so they can't be written earlier. - Ship —
pre-ship-securityfor a final security review of the finished code — plusrls-auditif the backend is Supabase, InsForge or another Postgres with an auto-generated API — thendeploymentfor CI/CD, monitoring, and rollback.
Field notes. Most skills carry a references/field-notes.md: failures from production apps that passed build, lint and tests, each with symptom, cause and how to check for it. When a specialist skill is active and the work is about to ship, read its field notes.
Building UI before the MVP is defined, or picking a stack before knowing the scale, produces rework. But secure-coding is never deferred — preventing a vulnerability is always cheaper than auditing one out later.
When NOT to route
If the user explicitly asks for one specific thing ("just give me a Tailwind navbar"), honor it and go straight to ui-design. Routing serves the user — it is not a toll booth. Use judgment: ambiguity means ask; clarity means act.
