Technical Glossary

93 terms across SaaS metrics, data engineering, AI, cloud FinOps, security & compliance, and engineering leadership, defined precisely, without padding.

SaaS & Investor Metrics

ARR

Annual Recurring Revenue: the total predictable revenue from all active subscriptions normalized to a yearly figure. The primary top-line metric investors use to evaluate SaaS growth rate and scale.

MRR

Monthly Recurring Revenue: the predictable subscription revenue earned in a single month. Used as a leading indicator; ARR is simply MRR × 12.

CAC

Customer Acquisition Cost: total sales and marketing spend divided by the number of new customers acquired. CAC payback period (months to recover CAC from gross margin) tells you how efficiently you are deploying growth capital.

LTV

Lifetime Value: the total gross profit generated by an average customer across their entire relationship with the company. A healthy LTV:CAC ratio is 3:1 or above; below 2:1 signals a unit economics problem.

Churn

Customer Churn Rate: the percentage of customers who cancel in a given period. Logo churn (customers lost) and revenue churn (ARR lost) tell different stories; revenue churn is more material at scale.

NDR

Net Dollar Retention: the percentage of ARR retained from existing customers after accounting for expansions, contractions, and cancellations. NDR above 120% means revenue grows even with zero new sales, the compounding engine of great SaaS.

Gross Margin

Revenue minus cost of goods sold (hosting, support, payment processing) as a percentage of revenue. SaaS companies typically target 70–80%+ gross margin. Below 60% signals infrastructure or delivery costs that need attention.

Unit Economics

The profitability profile of a single customer relationship: LTV, CAC, payback period, contribution margin. Healthy unit economics at Series A predict whether the business can scale without burning progressively more cash per customer.

NPS

Net Promoter Score: a single survey question ("How likely are you to recommend us?") scored -100 to 100. A useful directional signal, but easily gamed. Pairing it with actual retention data makes it meaningful.

DAU / MAU

Daily Active Users / Monthly Active Users. The ratio (DAU/MAU) measures stickiness: how often users return within a month. A ratio above 0.5 is strong for most SaaS products.

Rule of 40

ARR growth rate + EBITDA margin should exceed 40%. A framework investors use to balance growth and profitability. At Series A, growth dominates; at Series D and beyond, the margin component matters more.

Burn Multiple

Net cash burned divided by net new ARR. A burn multiple below 1 means you are generating a dollar of ARR for every dollar burned, capital-efficient growth. Above 2 starts raising questions at investor meetings.

SaaS

Software as a Service: software hosted and maintained by the vendor, accessed via the internet on a subscription basis. The delivery model shifts infrastructure costs to the vendor, enabling predictable recurring revenue.

Series A / B / C

Institutional funding rounds. Series A validates product-market fit. Series B funds scaling of a proven model. Series C and beyond expand into new markets or geographies. Each round involves increasing rigor on metrics, unit economics, and team depth.

Product-Market Fit

The state where a product meets a real market need so precisely that retention, referral, and expansion happen naturally. Marc Andreessen's original signal: you cannot build fast enough to meet demand. The operational signal: NDR above 110%, churn below 5% annually.

TAM / SAM / SOM

Total Addressable Market, Serviceable Addressable Market, Serviceable Obtainable Market: three narrowing estimates of market opportunity used in pitch decks. TAM is the total market if you owned it outright; SOM is what you can realistically capture in the next few years. Investors discount TAM heavily and weight SOM.

Magic Number

Net new ARR in a quarter divided by sales and marketing spend in the prior quarter. Above 0.75 signals efficient go-to-market spend worth scaling; below 0.5 means the sales motion needs fixing before adding budget.

ARR Multiple

A company's valuation divided by its ARR, the primary heuristic public and private markets use to price SaaS companies. Multiples compress when growth slows or rates rise; a 10x multiple at 40% growth and a 10x multiple at 100% growth reflect very different risk profiles.

Data Engineering

Data Lakehouse

An architecture that combines the low-cost storage of a data lake with the query performance and governance of a data warehouse. Databricks Delta Lake and Apache Iceberg are common implementations. Replaces the two-tier lake + warehouse pattern for most Series B data platforms.

Data Contract

A formal agreement between data producers and consumers about schema, semantics, SLAs, and ownership. The practice that prevents the "data swamp" failure mode where downstream teams cannot trust upstream data quality.

Event Streaming

A pattern where data is produced as a continuous stream of events (clicks, transactions, state changes) rather than batch files. Apache Kafka and Confluent are the dominant infrastructure. Enables real-time pipelines and decoupled microservice architectures.

Medallion Architecture

A layered data organization pattern with Bronze (raw ingestion), Silver (cleaned, validated), and Gold (business-ready) zones. Provides a clear quality progression and makes debugging data issues tractable. Standard at most modern data platforms.

Data Mesh

An organizational model that treats data as a product, owned and published by domain teams rather than a central data team. Requires data contracts, standardized interfaces, and a self-serve infrastructure platform. Solves scaling problems in organizations with 10+ data producers.

DAG

Directed Acyclic Graph: a dependency graph where each node is a task and edges define execution order, with no circular dependencies. The fundamental abstraction in pipeline orchestrators like Apache Airflow, Prefect, and Dagster.

dbt

Data Build Tool: a SQL-first transformation framework that brings software engineering practices (version control, testing, documentation, modularity) to data transformation. The standard tool for analytics engineering in the modern data stack.

ELT vs ETL

ETL (Extract, Transform, Load) transforms data before loading it into the warehouse. ELT loads raw data first, then transforms it inside the warehouse using SQL. Modern cloud warehouses (Snowflake, BigQuery, Redshift) made ELT the default by making in-warehouse compute cheap.

Reverse ETL

Moving data from the warehouse back into operational systems (CRM, sales tools, product). The data warehouse becomes the source of truth for customer data that flows downstream into every tool the business uses. Census and Hightouch are common tools.

Semantic Layer

A centralized layer that defines business metrics, dimensions, and their relationships independent of the underlying data model. Ensures every team uses the same definition of "revenue" or "active user." dbt Semantic Layer and Cube are common implementations.

Feature Store

A centralized repository for ML features, specifically the engineered inputs to a model. Serves features consistently between training and production, prevents training-serving skew, and enables feature reuse across teams. Feast and Tecton are common open-source options.

Change Data Capture

CDC: a pattern that captures every insert, update, and delete in a source database and streams those changes downstream in near-real-time. Enables event-driven architectures and real-time analytics without replicating the full database on each sync. Debezium is the standard open-source tool.

Data Observability

Monitoring the health, freshness, volume, schema, and distribution of data assets in production. The data equivalent of application observability. Monte Carlo and Great Expectations are common tools. A mature data platform ships with data observability as a first-class concern.

Orchestration

The automated scheduling, sequencing, and monitoring of data pipeline tasks. Orchestrators manage dependencies, retries, alerting, and backfills. Airflow remains the most widely deployed; Dagster and Prefect offer stronger developer experience.

Operational Data Store

A database optimized for real-time operational queries, specifically current state of customers, orders, or inventory, rather than historical analytics. Sits between the transactional system and the warehouse, serving latency-sensitive use cases that a warehouse cannot.

Data Warehouse

A centralized repository optimized for analytical queries over structured, historical data, distinct from a transactional database optimized for fast reads and writes on current state. Snowflake, BigQuery, and Redshift are the dominant cloud implementations.

OLAP vs OLTP

OLTP (Online Transaction Processing) systems handle high-volume, low-latency reads and writes on current state, the database behind your product. OLAP (Online Analytical Processing) systems handle complex aggregations over historical data, the database behind your dashboards. Running analytics queries against a production OLTP database is the most common cause of a self-inflicted outage.

Idempotency

The property of an operation that produces the same result no matter how many times it runs. Pipeline retries, backfills, and event replays all depend on idempotent writes; without it, a failed job that reruns silently duplicates data.

Backfill

Reprocessing historical data through a pipeline, typically after a bug fix, schema change, or new metric definition. The operation that separates pipelines that scale from pipelines that don't: idempotent, partitioned pipelines backfill in minutes; non-idempotent ones require manual cleanup first.

AI & Machine Learning

Context Engineering

The discipline of deliberately selecting, structuring, and retrieving the information an AI system receives, as distinct from prompt engineering, which concerns only the instruction layer. The practice that determines whether a production AI system produces reliable output or expensive noise.

RAG

Retrieval-Augmented Generation: a pattern that retrieves relevant documents from a knowledge base at inference time and injects them into the model context. Enables LLMs to answer questions about private or recent information without fine-tuning.

Vector Database

A database optimized for storing and querying high-dimensional embedding vectors by semantic similarity. The retrieval layer in most RAG implementations. pgvector (PostgreSQL extension), Pinecone, and Weaviate are common options. Most teams should start with pgvector before reaching for a dedicated service.

Embedding

A numerical representation of text, images, or other data as a fixed-length vector in a high-dimensional space. Semantically similar items cluster near each other in that space, enabling similarity search. The bridge between unstructured content and vector databases.

Fine-tuning

Continuing to train a pre-trained model on a smaller, domain-specific dataset to adapt its behavior. More expensive than prompt engineering and RAG; appropriate when the base model lacks the domain knowledge or output format you need, and you have enough labeled examples.

Prompt Engineering

The practice of crafting instructions to elicit desired behavior from a language model. Includes techniques like few-shot examples, chain-of-thought reasoning, and persona assignment. The fastest lever to improve AI output quality but the weakest guarantee: model updates can break prompts without warning.

Agentic AI

AI systems that autonomously plan and execute multi-step tasks by calling tools, accessing external data, and deciding next actions based on intermediate results. The shift from AI-as-generator to AI-as-operator. Production reliability requires explicit failure mode handling, cost controls, and human-in-the-loop checkpoints.

LLM

Large Language Model: a neural network trained on vast text data to predict and generate human language. The infrastructure layer behind GPT-4, Claude, Gemini, and Llama. Capabilities emerge from scale; specific behaviors come from fine-tuning and RLHF.

Foundation Model

A large model trained on broad data that serves as a base for downstream tasks through fine-tuning or prompting. LLMs are the most common type; multimodal foundation models handle images, audio, and code alongside text.

Hallucination

When a language model generates plausible-sounding but factually incorrect content. Not a bug to be patched but a fundamental property of probabilistic text generation. Mitigated by grounding responses in retrieved facts (RAG), citations, and structured output validation.

Token

The basic unit of text that a language model processes: roughly 0.75 words in English. Models have a context window measured in tokens (the amount of text they can "see" at once). Token count determines both cost and whether the model can process a given input.

Temperature

A parameter that controls output randomness in a language model. Temperature 0 produces deterministic, most-likely output. Higher values (0.7–1.0) introduce variation and creativity. For production systems with factual requirements, temperature 0 or near-0 is standard.

Tool Use

The ability of a language model to call external functions, including search, code execution, database queries, API calls, and incorporate results into its response. The mechanism that transforms a text generator into an autonomous agent. Also called "function calling."

Multi-agent System

An architecture where multiple AI agents collaborate on a task, each with a specialized role, passing context between steps. Enables parallelization and separation of concerns. Adds coordination complexity and failure surface; most production systems start with single agents and add agents when a measurable bottleneck appears.

Model Context Protocol

An open protocol (developed by Anthropic) for connecting AI models to external tools, data sources, and systems through a standardized interface. MCP servers expose capabilities that any compatible client can use without bespoke integration code. Becoming the emerging standard for AI tool connectivity.

Context Window

The maximum number of tokens a language model can process in a single request, spanning the system prompt, conversation history, retrieved documents, and the response itself. A larger context window reduces the need for aggressive retrieval and chunking, but cost and latency still scale with tokens used, not tokens available.

System Prompt

The instructions that configure a model's behavior, role, and constraints before a conversation begins, distinct from the user's messages. The primary lever for controlling tone, output format, and tool-use policy in a production application.

Evals

Evaluations: a test suite that scores a language model or AI system's outputs against defined criteria, run the way a CI test suite runs against code. The practice that separates AI products shipped on evidence from AI products shipped on vibes; without evals, every prompt or model change is a guess.

Guardrails

Constraints placed around a language model's inputs and outputs to prevent unsafe, off-topic, or non-compliant behavior: input validation, output filtering, and scope restriction. Necessary because prompt instructions alone are not a security boundary; a model can be persuaded to ignore them.

Agentic Coding

Using an AI agent to autonomously write, run, and iterate on code with minimal human intervention between steps, as opposed to AI-assisted coding, where a human reviews and accepts each suggestion. Raises output volume and lowers the marginal cost of a mistake reaching production, which is why review process matters more, not less, as adoption increases.

Cloud & FinOps

FinOps

Financial Operations for cloud: the practice of bringing financial accountability to the variable spend model of cloud infrastructure. Teams own their cloud costs, usage is tracked in real time, and decisions are made on unit economics rather than budgets. The FinOps Foundation defines the maturity framework.

Reserved Instances

A commitment to use a specific cloud resource (EC2, RDS, etc.) for 1 or 3 years in exchange for 30-60% lower pricing versus on-demand. The single highest-ROI cost optimization for stable, predictable workloads. Requires confident capacity forecasting, since over-committing is costly.

Spot Instances

Spare cloud capacity sold at 70–90% discount versus on-demand but interruptible with 2 minutes notice. Ideal for stateless, fault-tolerant workloads like batch processing, CI/CD runners, and ML training. Not suitable for stateful services or latency-sensitive APIs.

Committed Use Discounts

GCP's equivalent of AWS Reserved Instances: commitments to a specific vCPU and memory configuration for 1 or 3 years at discounted rates. Committed use and Savings Plans (AWS) are the primary mechanism for reducing cloud compute spend without changing architecture.

Right-sizing

Matching cloud resource allocation to actual usage rather than peak theoretical demand. A team running on oversized instances because "we might need it" is the most common source of cloud waste. Cloud provider tools (AWS Compute Optimizer, GCP Recommender) automate the analysis.

Cloud Waste

Cloud spend on resources that generate no business value: idle instances, unattached storage, orphaned load balancers, test environments left running. Industry estimates put average waste at 30–35% of total cloud spend. Tagging hygiene and automated shutdown policies are the primary remedies.

COGS

Cost of Goods Sold: in SaaS, the direct costs of delivering the product: cloud infrastructure, third-party APIs, customer support, and payment processing. COGS directly determines gross margin. Reducing COGS without affecting reliability is one of the highest-ROI CTO activities.

Infrastructure as Code

Managing and provisioning cloud infrastructure through code (Terraform, Pulumi, AWS CDK) rather than manual console clicks. Enables version control, repeatable environments, and peer review of infrastructure changes. A prerequisite for any organization running multiple environments reliably.

Egress Costs

Charges for data transferred out of a cloud provider's network. Ingress is typically free; egress can be significant for data-intensive products. Often invisible until the first large invoice. Multi-cloud and edge caching architectures are partly driven by egress cost optimization.

Availability Zone

A physically isolated data center within a cloud region. Distributing workloads across multiple AZs provides resilience against hardware and power failures within a single facility. Running in a single AZ for cost reasons is a reliability risk most production systems should not accept.

Kubernetes

An open-source system for automating deployment, scaling, and management of containerized applications across a cluster of machines. The de facto standard for running production workloads at scale, and a common source of cost overrun when clusters are over-provisioned for peak load that rarely occurs.

Serverless

A compute model where the cloud provider manages infrastructure provisioning and scaling automatically, and you pay per execution rather than per provisioned server. Eliminates idle capacity cost for spiky or low-traffic workloads; becomes more expensive than reserved compute at sustained high volume.

Autoscaling

Automatically adjusting the number of running compute instances in response to real-time load. Prevents both over-provisioning, paying for idle capacity, and under-provisioning, dropped requests during traffic spikes, provided the scaling policy is tuned to the workload's actual latency to scale up.

Total Cost of Ownership

TCO: the full cost of a system across its lifetime, including infrastructure, licensing, engineering time to build and maintain, and the opportunity cost of the team not building something else. The metric that should govern a build-versus-buy decision, not sticker price alone.

Security & Compliance

SOC 2

Service Organization Control 2: an audit framework certifying that a company's security, availability, and confidentiality controls meet a defined standard, commonly required by enterprise customers before signing a contract. Type I certifies controls exist at a point in time; Type II certifies they operated effectively over a period, typically 6-12 months, and carries more weight with buyers.

Zero Trust

A security model that assumes no user or system is trusted by default, inside or outside the network perimeter, and requires continuous verification for every access request. Replaces the older model of a hardened perimeter with a trusted internal network, which fails as soon as one internal system is compromised.

Principle of Least Privilege

Granting a user, service, or system only the minimum access required to perform its function, and nothing more. The single highest-leverage access control practice; most breaches that escalate from a minor compromise into a major one do so because a credential had far more access than its use case required.

SSO

Single Sign-On: authentication that lets a user access multiple systems with one set of credentials, verified once by a central identity provider. The baseline enterprise sales requirement; a SaaS product without SSO is disqualified from most mid-market and enterprise procurement processes before the first sales call.

MFA

Multi-Factor Authentication: requiring two or more independent forms of verification, a password plus a device, biometric, or hardware key, before granting access. Reduces account takeover risk by orders of magnitude compared to password-only authentication, since compromising a second factor requires a fundamentally different attack.

PII

Personally Identifiable Information: any data that can identify a specific individual, including obvious fields like name and email and less obvious ones like IP address or device ID. The classification that determines encryption, access control, and retention requirements for a given data field.

Penetration Test

An authorized simulated attack against a system to identify exploitable vulnerabilities before a real attacker does, performed by a third party for objectivity. Distinct from a vulnerability scan, which lists known weaknesses automatically; a pen test demonstrates whether those weaknesses are actually exploitable in context.

Engineering Leadership

DORA Metrics

Four metrics from the DevOps Research and Assessment group that predict software delivery performance: Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Time to Restore Service. The most evidence-backed framework for measuring engineering team health.

Deployment Frequency

How often a team successfully releases to production. Elite performers deploy on demand (multiple times per day). Deployment frequency is both a metric and a forcing function; teams that deploy frequently build the infrastructure and culture that makes deploying safe.

MTTR

Mean Time to Restore: the average time to recover from a production incident. A low MTTR is a function of observability, runbooks, and on-call culture.

Lead Time for Changes

The time from a code commit to that code running in production. Measures the end-to-end friction in your delivery pipeline: code review, CI, staging, deployment. Reducing lead time requires trunk-based development, automated testing, and fast CI pipelines.

Technical Debt

The accumulated cost of shortcuts taken during development that will need to be paid back later through additional work. Like financial debt, it accrues interest; a poorly designed subsystem slows every subsequent feature built on top of it. The CTO's job is to make the debt visible, not to eliminate it entirely.

Engineering Velocity

The rate at which an engineering team converts work into delivered value. Not measured in story points, but in outcomes: features shipped, incidents resolved, technical debt cleared. Velocity is a lagging indicator; lead time and deployment frequency are the leading ones.

On-Call Burden

The operational load placed on engineers who must respond to production incidents outside working hours. High on-call burden drives attrition and reduces the quality of regular engineering work through sleep deprivation and context switching. Reducing alert noise and improving MTTR are the primary levers.

Platform Engineering

Building internal developer platforms that abstract away infrastructure complexity and give product teams self-service access to deployment, observability, and data tooling. The organizational model that scales a platform team's impact without creating a bottleneck. Team Topologies describes the theoretical framework.

Inner Source

Applying open-source contribution patterns (pull requests, code review, maintainer ownership) to internal company codebases. Enables teams to contribute to shared libraries without going through a central team, reducing silos while maintaining quality gates.

Engineering Principles

Documented, agreed-upon rules that guide technical decisions across a team: how to handle errors, when to abstract, what to test, how to version APIs. Principles reduce cognitive load and make code reviews faster because the underlying decisions are already made.

Blameless Postmortem

An incident review process that treats failures as system and process gaps rather than individual error, focused on what allowed the mistake to happen rather than who made it. Teams that run blameless postmortems get more honest incident reports, because engineers stop hiding near-misses out of fear of blame.

Bus Factor

The number of people who would need to leave or become unavailable before a project stalls from lost knowledge. A bus factor of one on a critical system is a risk equivalent to a single point of failure in infrastructure, and should be treated with the same urgency.

Staff Engineer

A senior individual-contributor role with organization-wide technical scope and influence, distinct from a manager, whose leverage comes from technical direction, mentorship, and cross-team problem-solving rather than headcount. The role that lets strong engineers grow in impact without moving into people management.

RFC Process

Request for Comments: a written proposal circulated for structured feedback before a significant technical decision is made, capturing the problem, alternatives considered, and the tradeoffs of the chosen approach. Slows down individual decisions in exchange for fewer expensive reversals and a durable record of why a system looks the way it does.