Software glossary: 40 terms in one sentence each
The forty software terms a business owner meets when commissioning, running or taking over custom software, each explained in one plain sentence.
The short answer
Commissioning, running or taking over custom software means meeting a vocabulary that proposals, sprint reviews and hand-overs assume you know. The forty terms below cover almost all of it, each in one plain sentence. They fall into five groups: what is being built, how it is built, how it is run, how it is kept safe, and how the project is managed. When a term is used to justify a price, a delay or a decision, ask what it changes for your project and what the alternative would have been. The answer is usually shorter than the word suggested, and asking is how you stay the owner of your own project.
What is being built
| Term | In one sentence |
|---|---|
| Custom software | Software built for your business’s specific process rather than bought as a product, which is right when the process is your advantage or nothing on the market fits. |
| SaaS | Software as a service: a product you subscribe to and use in the browser, run by its vendor, right when your need is common. |
| Web application | Software that runs in the browser, on any device, without installation, which is how most business software is built now. |
| Mobile app | Software installed on a phone from an app store, justified when the phone’s hardware, notifications or offline use are essential. |
| Progressive web app | A web application that can be installed like an app and work offline, often the right answer between a website and a native app. |
| Internal tool | Software used only by your own staff, usually the fastest return on custom development. |
| Client portal | A logged-in area where customers see their own data, documents and status, replacing email and phone for routine questions. |
| Dashboard | A screen that shows the numbers people actually look at, which is fewer than they ask for. |
| Integration | A connection between two systems so data flows without retyping, such as orders into accounting. |
| API | An agreed way for one piece of software to ask another for something, and the basis of every integration. |
| Webhook | A message one system sends another the moment something happens, so the second does not have to keep asking. |
| Database | Where an application’s data lives, structured in tables or documents, and the thing that must be backed up and protected. |
| Multi-tenant | One application serving many customers with their data kept separate, which is how software products are built. |
How it is built
| Term | In one sentence |
|---|---|
| Tech stack | The set of languages, frameworks and services an application is built with, chosen for fit, longevity and how many people know them. |
| Framework | A foundation of tools and conventions for building applications, such as Next.js for web applications. |
| TypeScript | JavaScript with types, which catches a class of mistakes before the code runs and is why we write in it. |
| Repository | The versioned store of the code and its history, which the business must own. |
| Version control | The system that records every change, who made it and why, and lets any change be undone. |
| Prototype | A clickable mock-up of the interface, built before code, to test the idea and the flow cheaply. |
| MVP | The smallest version of the software that delivers real value to real users, built first to learn before building more. |
| User story | A short description of something a user needs to do and why, the unit of work in a software project. |
| Acceptance criteria | The specific conditions under which a user story is considered done, written before the work starts. |
| Technical debt | The accumulated cost of shortcuts, which makes every later change slower until it is paid down. |
| Refactoring | Improving the structure of code without changing what it does, which is how debt is repaid. |
| Code review | A second developer reading every change before it is merged, catching mistakes and spreading knowledge. |
| Automated tests | Code that checks the application’s behaviour on every change, so a change that breaks something is caught before users see it. |
How it is run and kept safe
| Term | In one sentence |
|---|---|
| Environment | A complete copy of the application for a purpose: development, preview, staging, production. |
| Pipeline | The automated sequence of checks, tests, build and deployment that every change passes through. |
| Deployment | Putting a version of the application live, ideally atomically and reversibly. |
| Rollback | Restoring the previous version in one step when a deployment turns out wrong. |
| Feature flag | A switch that turns a feature on or off for some or all users without a new deployment. |
| Monitoring | Automated watching of the application’s health, errors and performance, with alerts to people. |
| Error tracking | A service that collects every error users hit, with context, so bugs are found before they are reported. |
| Backup and recovery | Copies of the data, stored elsewhere and tested by restoring, plus a plan for how long recovery takes. |
| Authentication and authorisation | Proving who a user is, and deciding what they are allowed to do, the two halves of access control. |
| Audit log | A record of who did what and when in the application, needed for trust, compliance and investigating problems. |
| Secrets | API keys, passwords and tokens, which live in the platform’s secret storage and never in code. |
How the project is managed
| Term | In one sentence |
|---|---|
| Scope | What is included in a phase or a price, written down, and the thing every change request changes. |
| Sprint or iteration | A short fixed period, usually one to two weeks, at the end of which working software is shown. |
| Backlog | The ordered list of everything that could be built, from which each sprint draws. |
Using the glossary
- Read a proposal with the glossary open and place each term in its group.
- Check the ownership terms: repository, environments, secrets, in whose name and control.
- Check the quality terms: tests, review, pipeline, monitoring; whether they exist or are promised.
- Check the management terms: scope, acceptance criteria, sprints; whether you will see working software regularly.
- Ask about anything else in one sentence, and what it changes for you.
What this means for you
Forty terms cover almost every conversation about commissioning, building, running and managing custom software. Knowing them lets you read a proposal for what it delivers, a sprint review for what happened, and a hand-over for what you own. Ask about anything that does not fit, and treat words that cannot be explained plainly as a reason to ask more.
Frequently asked questions
Which terms matter most when commissioning software?
MVP and scope, because they decide what you get first; user story and acceptance criteria, because they decide how you know it works; repository, environments and pipeline, because they decide how safely it changes and what you own; API and integration, because most business software is about connecting to other systems; and maintenance, because software is never finished.
Why do software people use so many terms for the same thing?
Partly history, partly different traditions, partly marketing. Sprint and iteration, backlog and to-do list, staging and pre-production, monitoring and observability are near-synonyms in most contexts. When two terms seem to mean the same thing, ask whether the difference matters for your project; usually it does not.
A proposal uses a term that is not here. What should we do?
Ask for a one-sentence explanation and what it changes for you. Software has more vocabulary than any glossary can hold, and good partners explain it as they go. A term that cannot be explained plainly is either unimportant to you or doing persuasive work that the explanation should be doing instead.