Glossary
Plain-English definitions of technical terms that business owners encounter when evaluating, buying, or managing software projects.
RAG (Retrieval-Augmented Generation)
What It Actually Means Retrieval-augmented generation is a two-step arrangement. When a question arrives, the system first searches your own material for relevant passages, then hands those passages to a language model and asks it to answer using them. The model is not answering from memory. It is reading an extract you supplied and writing a reply based on it,...
Refactoring
What It Actually Means Refactoring is restructuring existing code without changing what it does from the outside. Same screens, same behaviour, same output. Different internals. That definition contains the entire commercial problem with refactoring, which is that a successful refactor is invisible to you. You fund a fortnight of work and receive a product that looks and behaves precisely as...
Repository
What It Actually Means A repository is the store holding a project’s code together with its complete history: every change, who made it, when, and why. Every developer working on it holds a full copy locally. A shared copy lives on a hosting service, usually GitHub, GitLab or Bitbucket, and that is the one everyone synchronises with. The Question That...
Responsive Design
What It Actually Means Responsive design means one site that adapts its layout to whatever screen it is viewed on, rather than a separate mobile version. It has been the standard approach for over a decade, so almost every current site is technically responsive. Which makes the question worth asking a different one: not whether the site fits a phone,...
Retainer
What It Actually Means A retainer is a recurring fee that reserves a supplier’s time and attention rather than buying a defined list of deliverables. That is the honest description, and it is the source of every argument retainers produce. You are buying availability. Some months you will use all of it and feel it was excellent value. Other months...
Reverse Proxy
What It Actually Means A reverse proxy sits in front of your application and receives every request before the application does. It decides what to do with each one, passes it on, and returns the response. Visitors never talk to the application directly. They talk to the proxy, which is usually Nginx, and often something like Cloudflare in front of...
Robots.txt
What It Actually Means Robots.txt is a plain text file at the root of your site telling well-behaved crawlers which paths they should not fetch. Two properties define what it can sensibly be used for. It is a request, honoured by reputable crawlers and ignored by anything malicious. And it is public, readable by anyone at yoursite.com/robots.txt. The Two Misconceptions...
ROI (Return on Investment)
What It Actually Means Return on investment compares what something cost with what it returned, expressed so that different uses of the same money can be compared. For software it is a genuinely useful discipline and a genuinely unreliable number, and holding both of those at once is the practical skill. Why The Number In The Proposal Is Usually Wrong...
Role-Based Access Control
What It Actually Means Role-based access control groups permissions into roles, then gives people roles rather than individual permissions. Instead of deciding thirty separate things about each new starter, you make them an Account Manager and they inherit what that means. When the definition changes, it changes once for everybody who holds it. That sounds like an implementation detail. It...
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.