Glossary
Plain-English definitions of technical terms that business owners encounter when evaluating, buying, or managing software projects.
GDPR
What It Actually Means UK GDPR governs how organisations handle information about living people. Not company data, not anonymous statistics: information that identifies someone. Its core demand is simpler than the industry around it suggests. Know what personal data you hold, have a lawful reason for holding it, keep it only as long as you need it, protect it sensibly,...
Generative AI
What It Actually Means Generative AI produces new output rather than judging existing input. Text, images, audio, code, video. The contrast worth holding is with the machine learning that businesses have used for years, which classifies and predicts: is this transaction fraudulent, which customers are likely to leave, what should this be filed under. That work continues and is frequently...
Git
What It Actually Means Git is the version control system that has become the near-universal standard. When a developer talks about committing, branching or merging, they are talking about Git. It runs locally. Every developer holds a complete copy of the history on their machine, which is why work can continue offline and why no single server holds the only...
GraphQL
What It Actually Means GraphQL is a way of building an API where the client specifies exactly what data it wants, in one request, and receives precisely that. The contrast is with the conventional approach, where the server defines fixed responses at fixed addresses. Fetching a customer, their orders and each order’s items might mean three or more separate requests,...
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.