Why this glossary exists
Every field has jargon, but software jargon has a particular cost: it appears in documents you are asked to approve and invoices you are asked to pay. Nodding through a term you half-understand in a kickoff meeting is how scope disputes are born three months later.
This glossary covers the terms that actually appear in proposals, quotes, and progress meetings for small business software projects. Each entry gives the plain meaning first, then — where it matters — what the term implies for your budget or your decisions. It is deliberately opinionated about that second part, because the definition is rarely the thing that bites.
The shape of the product
These terms describe what kind of thing is being built. They matter because they set expectations about cost, timeline, and what 'done' looks like.
MVP (minimum viable product)
The smallest version of a product that can test the core idea with real users. Budget implication: an MVP that takes six months is not an MVP; the word is doing marketing work in that sentence.
Prototype
A demonstration of an idea — often clickable screens with nothing real behind them. Useful for alignment; not a head start on the build. Do not pay for a prototype expecting version one minus polish.
Web app
Software used in a browser, no installation. Usually the cheapest serious option and the easiest to update for everyone at once.
Native app
Software installed from an app store, built specifically for iPhone or Android. Best access to notifications, camera, and offline use; typically the costliest path because each platform is its own build.
PWA (progressive web app)
A web app that behaves somewhat like an installed app — home screen icon, some offline ability. A middle path worth asking about before committing to native.
CMS (content management system)
The admin panel through which non-developers edit website content. If your team will update text or images, the words 'includes a CMS' — or their absence — belong in the quote.
The parts you can't see
Most of a software budget goes to things that never appear on screen. These are the terms for them.
Frontend
Everything the user sees and clicks. When people praise how software 'looks', they mean the frontend.
Backend
The logic and storage behind the screens — where bookings are saved, rules are enforced, and reminders are triggered. Usually the majority of the work, and invisible in a demo.
Database
Where the data lives: customers, bookings, jobs, messages. The key question for you is not which database, but who can access it and how it is backed up.
API (application programming interface)
The doorway one system offers another. 'It has an API' means other software can connect to it; 'we'll use their API' means your system will depend on someone else's doorway staying open.
Integration
Connecting your system to another — calendar, payments, accounting, WhatsApp. Each integration is real work and a real ongoing dependency; a quote that lists features but not integrations is incomplete.
Hosting / the cloud
The rented computers your software runs on. A modest monthly cost that continues forever, in an account you — not your developer — should own.
The words in the quote
These are the commercial terms — the ones that decide who pays when reality diverges from the plan.
Scope
The agreed list of what is included. The single most important word in the project: almost every dispute is a scope dispute wearing a costume.
Scope creep
The gradual expansion of that list through small, reasonable-sounding additions. Not villainy — entropy. Managed by having a written scope and a named process for changes.
Change request
The formal name for 'can we also add…' after work has started. Healthy projects expect them and price them openly; unhealthy projects absorb them silently until the relationship snaps.
Fixed price vs. time and materials
Fixed price buys certainty and punishes change; time and materials buys flexibility and requires trust. For a first engagement, a small fixed-scope phase is usually the safest structure.
Milestone
A defined checkpoint, usually tied to payment. Good milestones are demonstrable ('booking flow works end to end'), not calendrical ('end of March').
Retainer
A monthly fee reserving ongoing time for fixes and small changes after launch. The alternative is paying emergency rates for attention when something breaks.
The words in the check-in meeting
Terms you will hear while the work is underway — knowing them lets you follow a progress update without pretending.
Sprint
A short, fixed work cycle, commonly two weeks, ending with something reviewable. If you are shown nothing at the end of a sprint, ask why — the whole point is a steady rhythm of visible progress.
Staging
A private copy of the system where changes are tried before going live. 'It's on staging' means 'you can test it; customers can't see it yet'.
Production
The live system real customers use. 'Deployed to production' means the change is now real.
Bug vs. feature request
A bug is the software failing to do what was agreed; a feature request is asking it to do something new. The line matters because fixing bugs is usually included and new features usually are not — disagreements here are really scope disagreements.
Technical debt
Shortcuts taken to ship faster that make future changes slower until paid down. Some debt is rational; unmentioned debt is the kind that surprises you in next year's quotes.
QA (quality assurance)
Systematic testing before release. If a quote contains no testing time at all, the testing will happen anyway — performed by your customers.
How to use jargon you don't know
No glossary is complete, and new terms arrive constantly. The durable skill is not memorizing definitions — it is the habit of asking, in the meeting, "what does that mean for this project, in plain words?" Any builder worth hiring answers that question happily and concretely. Evasive or condescending answers to plain questions are among the most reliable early warnings you will ever get.
It may help to know the dynamic runs both ways: good developers prefer clients who ask. A client who understands what staging is, why scope is written down, and what a change request costs is easier to serve well. Asking plain questions does not mark you as naive — it marks you as the kind of client whose project tends to go smoothly.
Frequently asked questions
Do I need to learn technical terms before hiring a developer?
No — you need enough to follow the money and the decisions, which is roughly the contents of this page. Deep technical vocabulary is the builder's job. Your job is refusing to approve sentences you do not understand.
A proposal is full of terms not on this page. Bad sign?
Not necessarily — some projects genuinely need specialized language. The test is what happens when you ask for plain-language translation. A good builder provides it without friction; a proposal that stays foggy after questions is foggy on purpose or foggy in the author's own head. Both are warnings.
What is the single most important term here?
Scope. Nearly every software dispute — budget, timeline, disappointment — is at bottom a disagreement about what was included. A written scope, plus a named process for changing it, prevents more pain than any other habit on this page.
About the author
Ohad Mayrom — Founder, WizeApps
Ohad Mayrom is the founder of WizeApps, where he designs and builds booking systems, client intake flows, internal operations tools, and MVPs for small businesses and early-stage founders. He writes plain-language guides to help non-technical owners commission software with confidence.
Connect on LinkedInKeep reading
Thinking about building this?
Tell us what is not working yet. A few clear examples of the current workflow are enough to start a useful conversation.
Start a conversation