Glossary
Plain-English definitions of technical terms that business owners encounter when evaluating, buying, or managing software projects.
Fine-Tuning
What It Actually Means Fine-tuning takes an existing model and trains it further on examples you provide, adjusting its behaviour toward the patterns in those examples. The phrase people use is “training the AI on our data”, and that phrasing is the source of most of the confusion, because it implies the model will then know your data. That is...
Firewall
What It Actually Means A firewall controls which network traffic is allowed to reach a system. It works from rules: this kind of connection from these places is permitted, everything else is refused. The mental model most people carry is a wall around the building, and it is a reasonable one as far as it goes. The limitation is that...
Framework
What It Actually Means A framework is a foundation providing the structure and common machinery an application needs: handling web requests, talking to a database, managing users, organising code. Building without one means writing all of that yourself, badly, and maintaining it forever. Every serious project uses one. Framework Or Library A library is something your code calls when it...
Funnel
What It Actually Means A funnel describes the stages somebody passes through from first hearing of you to buying: aware, interested, considering, deciding, purchased. Fewer people remain at each stage, which is where the shape and the name come from. Its practical value is diagnostic. When enquiries are down, the funnel tells you where rather than merely that. Fewer people...
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.