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

Web vs. app boundary (important): design-taste-frontend owns 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 to ui-design instead. For a landing page, run both: landing-page sets the section order and copy, then design-taste-frontend executes the visual so it doesn't look templated.

Build the backend

Secure & monetize

legal-docs vive en su propio plugin, no en saas-builder: /plugin marketplace add MartinOlivero/saas-legal-docs → /plugin install legal-docs

Está 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 in pre-ship-security Step 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-page carries the principle.

Polish & ship

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.

1. product-discovery — define the problem, the user, and the MVP scope.
2. architecture-primer — decide the high-level system design and stack.
3. Build — multi-tenancy first 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). Add integrations when the product talks to a platform you don't control, and ai-features when it calls a model for its users. secure-coding runs throughout, not as a final step.
4. Monetize — payments when it's time to charge.
5. Polish — frontend-performance, accessibility, technical-seo, pwa as the product matures.
6. Legal — the legal-docs plugin (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.
7. Ship — pre-ship-security for a final security review of the finished code — plus rls-audit if the backend is Supabase, InsForge or another Postgres with an auto-generated API — then deployment for 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.