Glossary
Plain-English definitions of technical terms that business owners encounter when evaluating, buying, or managing software projects.
Dashboard
What It Actually Means A dashboard presents the current state of something in one view: numbers, charts, statuses, whatever is needed to see how things stand without opening five systems. It faces inward, to your team, which is what distinguishes it from a client portal. Why Most Get Abandoned The pattern is reliable. A dashboard is commissioned, delivered, admired, looked...
Data Breach
What It Actually Means A personal data breach is any security failure that leads to personal data being destroyed, lost, altered, disclosed or accessed without authorisation. Accidental counts. Internal counts. That definition is wider than most people assume, and the gap causes real problems, because businesses look for an attacker and conclude nothing happened. An email with client details sent...
Database
What It Actually Means A database is where an application’s information is stored: customers, orders, records, history. Structured so it can be found, changed and related to other information reliably. Most business systems use a relational database, where data lives in tables with defined relationships between them. Customers have orders, orders have lines, lines refer to products. The structure enforces...
Database Migration
What It Actually Means Database migration covers two quite different jobs that share a name, and confusing them causes real problems. The first is a schema migration: a small, routine, versioned change to the structure of a database that ships alongside a code change. Adding a column, adding an index. These happen constantly on any active system and are unremarkable....
Dependency
What It Actually Means A dependency is a piece of code your application uses that somebody else wrote and maintains: a payment library, a PDF generator, a date handler, an image processor. Modern software is assembled far more than it is written. A typical business application might directly use thirty or forty components, and those use others, and by the...
Deployment
What It Actually Means Deployment is moving new code from where it was written to where customers use it. That sounds procedural and it is one of the more revealing things about how a system is built, because deployment is where all the assumptions get tested at once. The Question Worth Asking How long does it take to get a...
Digital Transformation
What It Actually Means Digital transformation is changing how a business operates because software makes a different way of working possible. Not putting the existing process on a screen. Changing the process. The distinction is the whole thing. Taking a paper form and making it a web form is digitisation, and it is often worth doing. Digital transformation is realising...
Disaster Recovery
What It Actually Means Disaster recovery is the plan for getting the business working again after something takes it out: hardware failure, a provider outage, ransomware, a deletion nobody meant to make. Backups are one component. Disaster recovery is the whole sequence, including who decides, who acts, what order things come back in, and what the business does meanwhile. The...
DNS
What It Actually Means DNS is the system that turns a name people can remember into the address of an actual machine. Somebody types your domain, DNS answers with where to send them. It is worth understanding at one level of detail, because DNS problems are common, they present as several different symptoms, and they are frequently misdiagnosed as something...
Domain Name
What It Actually Means A domain name is the address people type to reach you. You do not own it outright; you register it for a period and keep it as long as you keep renewing. It is worth thinking of as a lease on the most important piece of property your business has online, because everything else depends on...
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.