# TEL303: Building SaaS-Grade Software https://www.telosready.com/skills/TEL303?v=1 The three-part framework Telos uses when building SaaS-grade software — covering core SaaS architecture, go-to-market readiness (onboarding and billing), and growth metrics (AARRR). Use when explaining what SaaS-grade means or planning a SaaS product build. ## Instructions # Building SaaS-Grade Software All software Telos builds is SaaS-grade. This means SaaS-level security and architecture patterns are baked in from the beginning — not retrofitted later. This skill is organised into three parts. The right parts to apply depend on where you are taking the product. | Part | Scope | When to apply | |------|-------|---------------| | Part 1 — SaaS Foundation | Multitenancy, security, CI/CD, UX patterns | Always — custom SaaS or market SaaS | | Part 2 — Go-to-Market Readiness | Onboarding, billing | Only if taking the product to market | | Part 3 — Growth Metrics | AARRR pirate metrics | Only if growing a product in a market | If you are building custom SaaS for a single business, Part 1 is all you need. Parts 2 and 3 can be deferred and added later if the product moves toward a market — there is no architectural penalty for starting with Part 1 only. --- ## Part 1 — SaaS Foundation This is the baseline for every product Telos builds. It applies whether the software is for internal use or a commercial market. ### Multitenancy Every application is designed for multitenancy from day one, following a B2B pattern: - **Organisation** — represents a company or business entity - **Multi-user** — each organisation manages its own users; users can belong to multiple organisations This produces a multi-tenant, multi-user environment that supports any B2B deployment model without rearchitecting later. ### Security Telos uses **Clerk** for authentication and identity management. This provides: - Two-factor authentication enabled by default - A foundation for SOC 2 compliance when required - Consistent, auditable identity across all tenants Security is not an afterthought — it is part of the platform layer (see TEL302). ### CI/CD and Monorepo Rapid deployment is non-negotiable for SaaS. Every project includes: - Fully scripted CI/CD pipelines - A single codebase (monorepo) containing application code, database migrations, and configuration - End-to-end delivery from one repository — no fragmented deployment chains This enables changes to be deployed quickly and reliably throughout the product's life. ### UX Patterns B2B software increasingly interacts with AI agents and automated tools, not just human users. This shapes how UI is designed: - Follow familiar, standard B2B UI patterns to minimise learning curve - Reserve design effort for high-value, high-frequency screens (dashboards, visualisations, schedules, timelines) - Lower-frequency screens follow best-practice B2B conventions without custom design investment This keeps the product coherent and ensures the highest-effort screens are the ones users interact with most. --- ## Part 2 — Go-to-Market Readiness Apply this part when the product will be offered to external customers, either through self-service or a managed onboarding process. ### Onboarding Onboarding is the on-ramp to your product. A six-lane motorway is useless without it. **For custom SaaS (single business):** onboarding can be done once, manually, with direct support. **For market SaaS (self-service):** customers must be able to onboard themselves. This typically includes: - Guided setup steps that walk users through initial configuration - Data import tools for bringing in existing records - In-product training that teaches the product while setting it up The goal is to get users from zero to active as fast as possible. Every friction point in onboarding is a lost customer. ### Billing **For custom SaaS:** billing is not needed — the commercial relationship is handled outside the product. **For market SaaS:** integrate **Stripe** to handle billing. Common models include: - Monthly subscription (per seat or per organisation) - Consumption-based (usage-driven pricing) - Freemium with paid tiers The billing model choice depends on the market and product — Stripe supports all of them. What matters is that billing is integrated from launch, not added later. --- ## Part 3 — Growth Metrics (AARRR) Apply this part when actively growing a SaaS product in a market. These are the five metrics — known as the Pirate Metrics — that determine whether a product is working. Parts 1 and 2 get you to the starting line. Part 3 is where the real work begins. ### The Five Metrics **1. Acquisition** — Can you bring customers in? - The measure: does the market have a compelling problem that your product addresses? - At acquisition stage, prospects resonate with the problem — they do not yet know if the software solves it - Focus: go-to-market strategy, messaging, and reach **2. Activation** — Does the software solve the problem? - The measure: do users become active after signing up? - A user who resonates with the problem but cannot get value from the product is an acquisition win and an activation failure - Focus: UX, onboarding quality, and time-to-value **3. Retention** — Do users come back? - The measure: do users return on a weekly or monthly basis? - Software must embed itself into daily or weekly workflows — if it does not, users forget it exists - Focus: ongoing value, habit formation, and workflow integration **4. Revenue** — Will users pay? - The measure: can users reach "can't live without it" and convert to paid? - This may follow a free trial or emerge naturally from retention - Focus: pricing model, conversion triggers, and value demonstration **5. Referral** — Do users tell others? - The measure: do users invite colleagues, share content, or recommend the product? - Referral is compounding — it reduces acquisition cost over time - Focus: sharing mechanics, network effects, and product advocacy ### What Part 3 Requires Growing through the AARRR funnel is significantly more work than building the product. It requires: - Continuous user research and listening - Marketing and go-to-market execution - Improving conversion rates at every stage of the funnel - Work that happens largely outside the product itself Measure each metric. Identify the weakest stage. Focus improvement effort there before moving to the next.← Skills Directory
TEL303
Building SaaS-Grade Software
The three-part framework Telos uses when building SaaS-grade software — covering core SaaS architecture, go-to-market readiness (onboarding and billing), and growth metrics (AARRR). Use when explaining what SaaS-grade means or planning a SaaS product build.
# Building SaaS-Grade Software All software Telos builds is SaaS-grade. This means SaaS-level security and architecture patterns are baked in from the beginning — not retrofitted later. This skill is organised into three parts. The right parts to apply depend on where you are taking the product. | Part | Scope | When to apply | |------|-------|---------------| | Part 1 — SaaS Foundation | Multitenancy, security, CI/CD, UX patterns | Always — custom SaaS or market SaaS | | Part 2 — Go-to-Market Readiness | Onboarding, billing | Only if taking the product to market | | Part 3 — Growth Metrics | AARRR pirate metrics | Only if growing a product in a market | If you are building custom SaaS for a single business, Part 1 is all you need. Parts 2 and 3 can be deferred and added later if the product moves toward a market — there is no architectural penalty for starting with Part 1 only. --- ## Part 1 — SaaS Foundation This is the baseline for every product Telos builds. It applies whether the software is for internal use or a commercial market. ### Multitenancy Every application is designed for multitenancy from day one, following a B2B pattern: - **Organisation** — represents a company or business entity - **Multi-user** — each organisation manages its own users; users can belong to multiple organisations This produces a multi-tenant, multi-user environment that supports any B2B deployment model without rearchitecting later. ### Security Telos uses **Clerk** for authentication and identity management. This provides: - Two-factor authentication enabled by default - A foundation for SOC 2 compliance when required - Consistent, auditable identity across all tenants Security is not an afterthought — it is part of the platform layer (see TEL302). ### CI/CD and Monorepo Rapid deployment is non-negotiable for SaaS. Every project includes: - Fully scripted CI/CD pipelines - A single codebase (monorepo) containing application code, database migrations, and configuration - End-to-end delivery from one repository — no fragmented deployment chains This enables changes to be deployed quickly and reliably throughout the product's life. ### UX Patterns B2B software increasingly interacts with AI agents and automated tools, not just human users. This shapes how UI is designed: - Follow familiar, standard B2B UI patterns to minimise learning curve - Reserve design effort for high-value, high-frequency screens (dashboards, visualisations, schedules, timelines) - Lower-frequency screens follow best-practice B2B conventions without custom design investment This keeps the product coherent and ensures the highest-effort screens are the ones users interact with most. --- ## Part 2 — Go-to-Market Readiness Apply this part when the product will be offered to external customers, either through self-service or a managed onboarding process. ### Onboarding Onboarding is the on-ramp to your product. A six-lane motorway is useless without it. **For custom SaaS (single business):** onboarding can be done once, manually, with direct support. **For market SaaS (self-service):** customers must be able to onboard themselves. This typically includes: - Guided setup steps that walk users through initial configuration - Data import tools for bringing in existing records - In-product training that teaches the product while setting it up The goal is to get users from zero to active as fast as possible. Every friction point in onboarding is a lost customer. ### Billing **For custom SaaS:** billing is not needed — the commercial relationship is handled outside the product. **For market SaaS:** integrate **Stripe** to handle billing. Common models include: - Monthly subscription (per seat or per organisation) - Consumption-based (usage-driven pricing) - Freemium with paid tiers The billing model choice depends on the market and product — Stripe supports all of them. What matters is that billing is integrated from launch, not added later. --- ## Part 3 — Growth Metrics (AARRR) Apply this part when actively growing a SaaS product in a market. These are the five metrics — known as the Pirate Metrics — that determine whether a product is working. Parts 1 and 2 get you to the starting line. Part 3 is where the real work begins. ### The Five Metrics **1. Acquisition** — Can you bring customers in? - The measure: does the market have a compelling problem that your product addresses? - At acquisition stage, prospects resonate with the problem — they do not yet know if the software solves it - Focus: go-to-market strategy, messaging, and reach **2. Activation** — Does the software solve the problem? - The measure: do users become active after signing up? - A user who resonates with the problem but cannot get value from the product is an acquisition win and an activation failure - Focus: UX, onboarding quality, and time-to-value **3. Retention** — Do users come back? - The measure: do users return on a weekly or monthly basis? - Software must embed itself into daily or weekly workflows — if it does not, users forget it exists - Focus: ongoing value, habit formation, and workflow integration **4. Revenue** — Will users pay? - The measure: can users reach "can't live without it" and convert to paid? - This may follow a free trial or emerge naturally from retention - Focus: pricing model, conversion triggers, and value demonstration **5. Referral** — Do users tell others? - The measure: do users invite colleagues, share content, or recommend the product? - Referral is compounding — it reduces acquisition cost over time - Focus: sharing mechanics, network effects, and product advocacy ### What Part 3 Requires Growing through the AARRR funnel is significantly more work than building the product. It requires: - Continuous user research and listening - Marketing and go-to-market execution - Improving conversion rates at every stage of the funnel - Work that happens largely outside the product itself Measure each metric. Identify the weakest stage. Focus improvement effort there before moving to the next.