Glossary
Plain-English definitions of technical terms that business owners encounter when evaluating, buying, or managing software projects.
A/B Testing
What It Actually Means A/B testing shows two versions of something to different visitors at random and measures which produces more of the outcome you want. It is the closest thing marketing has to an experiment, and its appeal is obvious: instead of arguing about whether the green button works better, find out. The Problem Most Businesses Have You probably...
Agile
What It Actually Means Agile is building software in short cycles, showing working results frequently, and adjusting as you learn, rather than planning everything in advance and delivering once at the end. The reasoning is sound and worth stating plainly: nobody knows exactly what they need at the start. Not you, and not the people building it. Long detailed plans...
AI Agent
What It Actually Means An AI agent is given a goal rather than a script, and can take actions to pursue it: calling systems, reading records, deciding what to do next based on what it finds. The distinction from a chatbot is doing versus saying. A chatbot answers. An agent looks up the order, checks the stock, issues the refund...
AI Hallucination
What It Actually Means A hallucination is when an AI system produces something fluent, confident and false. An invented citation, a policy that does not exist, a customer record it has no basis for, a legal case nobody ever tried. The word is unhelpful because it suggests a malfunction, something that occasionally goes wrong and could be fixed. That is...
API
What It Actually Means An API is a defined way for one piece of software to talk to another: a set of requests it will accept and answers it will give. The everyday version is that it is how your systems can share information without a person copying it between them. Your website sends an enquiry to your CRM. Your...
API Key
What It Actually Means An API key is a string identifying your system to somebody else’s. You present it with each request and their system decides what you are permitted to do. It is a credential. That is the whole point and it is routinely forgotten, because a key looks like configuration rather than like a password, and gets handled...
Audit Trail
What It Actually Means An audit trail is a record of who did what, to which record, and when. Not what the data says now, but how it came to say it. The distinction between a log and an audit trail is worth holding onto. A log is written for engineers, to diagnose faults, and it is usually rotated away...
Authentication
What It Actually Means Authentication is proving who someone is. It is the login: the point at which an anonymous visitor becomes a known person. It answers exactly one question, and it is important to be precise about which one, because the confusion between this and what comes next causes real problems. Authentication establishes identity. It says nothing whatsoever about...
Authorisation
What It Actually Means Authorisation decides what a known user is allowed to do. It follows authentication, which established who they are. The two get discussed as one topic and they behave very differently. Authentication happens once, at a single point, at the start of a session. Authorisation has to happen continuously, at every point where the system shows information...
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.