Glossary
Plain-English definitions of technical terms that business owners encounter when evaluating, buying, or managing software projects.
Tailwind CSS
What It Actually Means Tailwind is a way of styling web pages using many small utility classes applied directly in the markup, rather than writing separate stylesheets describing how each element should look. Instead of naming an element and styling that name elsewhere, the styling is expressed in place as a string of small instructions: padding, colour, size, spacing. Why...
Technical Debt
What It Actually Means Every codebase contains decisions that were right at the time and are wrong now. A shortcut taken to hit a deadline. A structure that made sense when the product did one thing and does not now that it does nine. Technical debt is the accumulated cost of those decisions, and the name is well chosen: like...
Token
What It Actually Means A token is a string that proves an identity or a permission without a password being sent. Something checks it and decides what the holder may do. You meet them in two places. After you log in, your session is usually held as a token rather than by re-sending your password on every click. And when...
Training Data
What It Actually Means Training data is the material a model learned from. Everything it can do, and every way it is wrong, traces back to it. For a large language model that means an enormous quantity of text gathered largely from the public internet, books and code. For a machine learning model built for your business, it means your...
Two-Factor Authentication
What It Actually Means Two-factor authentication requires two different kinds of proof before an account opens: something you know, and something you have. The password is the first. The second is a code from an app, a tap on a phone, or a physical key. The point is that the two are independent, so stealing one does not deliver the...
About the Glossary
Why Plain Language Matters More Than Technical Fluency
Every software project involves terminology that business owners are expected to understand but rarely have reason to learn. Developers use terms like API, CI/CD, middleware, and bearer token as if everyone shares the same vocabulary. When a client nods along without fully understanding, decisions get made on incomplete information. That gap between technical language and business understanding is where the most expensive mistakes happen: approving architectures you cannot evaluate, signing off on testing strategies you cannot verify, and accepting timelines based on concepts you have not had properly explained.
This glossary exists to close that gap. Each entry provides a plain-English definition, an explanation of why the term matters to your business, and a concrete example of the concept in action. These are not textbook definitions written for computer science students. They are practical explanations for the person who needs to make decisions about software without becoming a developer in the process.
We built this glossary from the questions our clients ask in discovery calls, during project reviews, and in Slack threads where someone finally admits they are not sure what a term means. The entries reflect what business owners need to understand, not what a technical writer thinks is important. Across hundreds of client engagements, we have found that the single biggest predictor of a smooth project is a client who understands enough vocabulary to ask the right questions. Not to write the code. Just to evaluate the answers they are given.
The definitions here deliberately link to deeper content elsewhere on the site. If a glossary entry sparks a question about how we implement something, the Knowledge Center, Services, and Systems sections have the full picture. The glossary is the starting point, not the destination.
Need a Term Explained?
If you have come across a term we have not covered yet, let us know and we will add it.