A Plain-English Glossary for Anyone Commissioning Software

Commissioning software means reading documents written in a dialect nobody taught you, where the important distinctions are often buried in words that sound interchangeable. This is a short translation of the terms that come up most, and why each one matters to you rather than to an engineer.

A general rule before the list: a good supplier can explain any of these in one sentence without a diagram. Reluctance to do so is rarely about complexity.

What you are buying

• Prototype: something built to answer one question, intended to be discarded. If discarding it would hurt, it is not one. See prototype or MVP.
• MVP: the first version of a product you intend to keep. Minimal refers to its scope, not its quality.
• Scope: the agreed list of what is being built. Most disputes are scope disputes wearing other clothes.
• Technical debt: shortcuts taken deliberately to go faster now, which cost more later. Not automatically bad; unacknowledged debt is.
• Refactoring: changing how code is organised without changing what it does. Invisible to you, and sometimes the reason a later feature is cheap.

The parts of a system

• Front end: what a person sees and clicks, in a browser or an app.
• Back end: the part on a server that holds data and enforces rules. Where most of the real work usually is.
• API: a defined way for two systems to talk. When a quote mentions integrations, this is what it means.
• Database: where the information lives. How it is structured early on shapes what is cheap to change later.
• Admin panel or back office: the screens your staff use. Frequently omitted from briefs and never optional.

Money, access and trust

• Authentication: proving who someone is. Authorisation: deciding what they may do. Different problems, and the second is where data leaks come from.
• Webhook: one system telling another that something happened, server to server. The reason a payment can be trusted; see payment webhooks.
• Row-level security: rules the database itself enforces about who may read which records. See why one user can read another's data.
• API key or secret: a credential your software uses. Some are safe in a browser and some are catastrophic there; see the key that ignores your rules.
• Encryption in transit and at rest: scrambling data while it travels and while it is stored. Both are table stakes, not features.

Getting it live, and keeping it live

• Environment: a copy of the system. Production is the real one with real customers; staging is the safe copy for testing.
• Deployment: putting new code live. If this is described as risky or manual, that is a cost you will pay repeatedly.
• CI/CD: automation that checks and releases code. It mostly means releases are routine rather than events.
• Hosting: where it runs, and whose account it runs in. Ask whose name is on it before work starts.
• Uptime and monitoring: whether it is working, and whether anyone finds out when it is not. A system nobody watches fails silently.

Mobile-specific words

• Native, cross-platform and web app: three ways to build for phones, with real trade-offs; none is universally correct.
• Store review: the approval process before an app is published, and a common source of delay. See why Google Play rejected your app.
• Signing key: the credential that proves an app update came from you. Lose it and you cannot update your own app, ever.
• Target API level: the platform version an app is built against. It rises annually and ignoring it eventually blocks updates.
• Offline-first: an app that works without a connection, which is easy until two people change the same thing; see offline sync.

AI words worth pinning down

• AI builder: a tool that generates a working application from a description. Genuinely useful, with a predictable gap before production; see from prototype to production.
• Model: the underlying system doing the generating. Which one is used affects cost and behaviour, and it changes often.
• Prompt: the instructions given to a model. When a supplier says prompt engineering, they mean writing and testing those instructions.
• Hallucination: a model producing something confident and wrong. It is a property of how they work, not a bug that gets fixed.
• Fine-tuning versus retrieval: training a model on your data, versus giving it your data to read at the time. The second is usually what people actually need.

The words in the contract

• Fixed price versus time and materials: who carries the risk that the work is bigger than it looked. Neither is a discount.
• Intellectual property assignment: the clause that makes the code yours. Check it exists, and check when it takes effect.
• Handover: what you get at the end. Ask for specifics before signing; see choosing a development partner.
• Maintenance or support retainer: ongoing work after launch. Worth agreeing what it covers, because the word alone means little.
• Change request: the mechanism for altering agreed scope. Its existence is healthy; frequent use usually means the scope was never settled.

If a term in your quote is not here and nobody will explain it plainly, that is worth pressing on. The vocabulary exists to be precise, not to be impressive, and precision is something you are entitled to.

If you would like a quote or a brief translated into plain language before you commit to it, send it over. We will tell you what it actually commits you to, including when the honest answer is that it looks reasonable.