Glossary
The words that come up on a software project, and what they actually mean. Grouped by roughly when you’ll run into them.
We end up explaining a lot of these on calls. Not because they’re complicated, but because everyone in the room already knows them, so nobody stops to say what they mean. Then you’re a few weeks in, someone mentions the back end isn’t done, and it feels a bit late to ask.
So here they all are. They’re grouped by roughly when they come up rather than alphabetically, which makes it about a fifteen minute read start to finish. Or just search when something lands in your inbox.
Words from the proposal stage, most of which show up again later.
The smallest working version people can actually use. It's there to find out whether the idea works, not to be the finished thing.
In practiceWhen you hear "that's not in the MVP," it usually means not yet, and sometimes never. Worth asking which one you're getting.
The list of work the agreement covers. If something isn't on the list, it isn't happening yet.
In practice"Out of scope" isn't a no, and it isn't a comment on whether the idea is any good. It means it needs a new agreement, or something else comes off the list to make room.
Something you can actually point at: a working page, a document, access to an account. Not "progress."
In practiceThese often start a clock. A lot of agreements give you a set window to review and respond, and after that it counts as accepted.
Your sign-off that something is done. "Deemed accepted" means it signs itself off if nobody says anything in time.
In practiceIt's easier on everyone when the criteria are things you can check. "Loads quickly" is hard to settle later. "Loads in under three seconds on a phone" isn't.
Time and materials means you're paying for hours. Fixed fee means you're paying one price for a defined result, however long it takes.
In practiceWorth being clear which one you're in. Under time and materials the budget buys hours, not a finished list of features. Both are normal, they just put the risk in different places.
A written agreement to change what's getting made, what it costs, or when it's due. Until there's one, the original terms hold.
In practiceA good habit: when something new goes in, ask what comes out. It keeps the budget honest without anyone having to be the bad guy.
The code, designs, and documents made for you. Assignment means ownership moves to you instead of staying with whoever wrote it.
In practiceUsually tied to payment. It also won't cover every piece inside the product, since some parts come from elsewhere and keep their own terms. That's normal.
Outside companies your app runs on, billed monthly. One serves the site, one stores the data, one sends the email. Closer to a utility bill than to anything anyone writes.
In practiceThese are usually your cost, separate from the project fee. Simplest if the accounts are in your company's name on your card, with your developer invited in rather than the other way around.
Words you'll hear when someone shows you something. We tend to skip ahead to a working screen, but the vocabulary still comes up.
Everything a person sees and touches. Buttons, text, forms, layout.
Whether using it actually works. How many steps, how confusing, whether people finish what they started.
In practice"Good UI, bad UX" is a real verdict. It means it looks great and nobody can get through it.
How finished a design drawing looks. Low fidelity is grey boxes and placeholder text. High fidelity looks like the real product, fonts and photos included.
In practiceIf someone shows you a drawing, it helps to ask which kind it is. A rough one is asking you about the order of the steps. A polished one is asking about the details.
The rough version. Boxes and labels showing what goes where, no styling.
A detailed picture of a finished screen. It's an image, so nothing in it works.
Mockups linked together so you can click from one to the next. Still nothing underneath, so no data gets saved and no email goes out.
In practiceA good one feels real, which is the catch. If you're not sure whether you're looking at a prototype or the actual product, just ask.
The step-by-step path one person takes to finish one task, from landing on the homepage to a confirmed order.
In practiceWorth spending your attention here. It's really a sequence of steps, so you can read it the same way you'd read any process at your company.
A piece of interface made once and reused everywhere. A button, a card, a form field. Change it in one place and it changes everywhere.
The layout rearranges to fit whatever screen it lands on. Mobile-first means the phone version gets designed first and the desktop version comes from it.
In practiceMost people will see it on a phone, so it helps to review it on one. Things that only ever get approved on a laptop tend to have surprises.
What a screen shows when there's nothing in it yet. No orders, no messages, no history.
In practiceYour first users see nothing but these. They're the most looked-at screens in a new product and the easiest ones to forget.
The happy path is everything going right. An edge case is everything else: the misspelled email, the person who quits halfway, the order with two addresses on it.
In practiceDemos show the happy path. Real people find the edges fast. "What happens if I do this wrong?" is a good question to ask at a demo.
Whether people with impaired sight, hearing, or movement can use it. Readable contrast, keyboard navigation, screen-reader labels, text that scales.
In practiceMuch easier to handle as you go than to add later. It's also a legal question if you sell to the public or to government.
The words in the product. Microcopy is the small stuff: button labels, error messages, the line under the form field.
In practiceThe words do a lot of the work, and they're the cheapest thing in the product to change.
Some of this is genuinely useful. Some of it was invented for teams of forty and doesn't mean much on a team of two.
The running list of everything that could get done, in priority order. Being on it doesn't promise anything.
In practice"I'll add it to the backlog" means written down, not scheduled. Reasonable follow-up: where does it sit, and what moves if this goes up?
One numbered item of work, either a bug to fix or something to make, with a description and a status.
A fixed block of time, usually one or two weeks, with a set of items due at the end.
In practiceNothing is lost when something slips, it just moves to the next one. One thing slipping is normal. The same thing slipping twice is worth a conversation.
A checkpoint where a chunk is done, usually tied to a review, a payment, or a decision about whether to keep going.
The work growing past what was agreed, one reasonable request at a time.
In practiceThis is the most common way a small project drifts, and it usually happens without anyone deciding to. Nothing feels like a big ask on its own.
Taking planned work out on purpose to protect the date or the budget.
In practiceA normal move rather than a failure. On a fixed budget it's often the only lever there is.
Something that stops work until it's resolved. Often a decision or a login that only you can give.
In practiceWorth keeping half an eye on, since a few days waiting on an answer is a few days of budget sitting still.
A shortcut taken to hit a date. It works, and it makes later changes slower until someone goes back and tidies it.
In practiceSome of it is fine, especially early. The useful question isn't whether there's any, it's what got skipped and whether it's written down anywhere.
Rewriting existing code to be cleaner without changing what it does. Nothing visible happens.
In practiceA week of this produces nothing you can see, and it's sometimes exactly right. Fair to ask what gets faster or safer afterward.
Waterfall means deciding everything up front and working to the plan. Agile means going in small pieces and adjusting as you learn. Most modern software work calls itself agile.
In practiceAdjusting as you learn is the good part. It shouldn't mean nobody can tell you what you'll have by a given date.
The polite way of saying later. Phase 2 is where good ideas wait while the current budget stays intact.
In practiceSometimes it really is coming, sometimes it's a gentle no. Both are fine, it just helps to know which one you got.
You won't touch any of this. You'll hear all of it, and following the sentence makes the whole thing feel a lot less opaque.
The front end is everything you see and click. The back end is the part nobody sees that stores records, checks who's allowed to do what, and does the actual work.
In practice"The front end is done, the back end isn't" means the screens are there but clicking things doesn't do much yet. Also worth knowing that something small at the counter can be big in the back office, and the other way around.
Where the information lives. Every customer, order, message, and job.
In practiceWhat you collect is a lot easier to settle before launch than after, since every record already saved has to line up with anything you add later.
An agreed way for two pieces of software to talk. Your app asks another system a question in a set form and gets back a set kind of answer.
In practiceEach one is a vendor relationship. Their outage is your outage, and their price change is your cost.
A ready-made foundation developers work on top of instead of starting from nothing. Next.js and React are the common ones for web products.
In practiceMostly not your problem, except that it decides who else can pick up your product later. Common choices mean a bigger pool of people who can.
The single online folder holding all the code, plus every edit ever made to it. Usually on a site called GitHub.
In practiceWorth asking to be an owner early rather than at the end. Until then, owning the code is a line in a contract rather than something you're holding.
The system that records every change, with who made it, when, and why, and lets any earlier version of the whole thing come back exactly.
Publishing a version so it's reachable on the internet.
In practiceIt happens often, sometimes a few times a day, and the previous version can usually come back in minutes. Less dramatic than it sounds.
Separate copies of the app. Local is on the developer's own machine. Preview is a private copy at its own web address. Production is the real one.
In practiceYou'll review most work through a preview link. It looks like the real thing, which is the catch: the data in it is fake, so an order or an email that seemed to go through didn't go anywhere.
Authentication proves you are who you say. Signing up, logging in, resetting a password. Authorization decides what you can do once you're in.
In practiceTwo different things in one word. The second is where privacy problems tend to live. Less "can a stranger log in" and more "can one customer see another customer's pricing."
The domain is your web address. DNS is the directory that points it at the machine serving the site.
In practiceWorth having registered to your company, on your account. It's the one thing that's a real headache to get back if it lives somewhere else.
The rented computers your app runs on, billed monthly, scaling with how much traffic you get.
The first one here settles more arguments than the rest of this page put together.
A bug is the software doing something other than what was agreed. A change request is it doing exactly what was agreed, and you wanting something different.
In practiceBugs get fixed as part of the work. Change requests use budget. Mixing the two up causes more friction than almost anything else, in both directions. "It works, I just don't like it" is a change request, and saying so plainly keeps things easy.
A change that fixes the thing it was meant to fix and quietly breaks something that used to work.
In practiceThis is why "it's a small change" isn't a great guide to cost. Nobody can hold every connection in a system in their head at once.
Someone going through the product trying to break it, on the theory that whoever made it can't see its problems anymore.
In practiceThere are too many possible paths to check all of them, so this lowers the risk rather than removing it. Some things still get through.
Checks written once that re-run on every change to confirm the old behavior still holds.
In practiceThey cost time now and save it later. Having them on the parts that really can't break and skipping the rest is a reasonable call on a first project.
Rollback is putting the previous working version back after a bad release. Downtime is any stretch where the site isn't reachable.
In practice"We rolled it back" is good news. It means someone caught it and undid it in minutes.
A second developer reading a change before it becomes part of the product.
In practiceOn a one-person project there's no second reader, so automated checks and your own look at the screens fill in. Fine to ask what's covering it.
Words for working out whether it worked.
Opening to a small invited group first, so the problems get found by people who forgive them.
Everything between someone arriving and someone actually set up and using it.
In practiceThis is where most new products lose most people, usually in the first couple of minutes.
The moment someone does the thing that means they got it. Not signing up, but reaching the first real bit of value.
In practiceWorth defining precisely for your own product. It's usually the number that tells you whether the thing is working.
The steps toward a goal with the count of people surviving each one. Drop-off is where they quit.
In practiceProbably the most useful single view you can have. It turns "it feels like people aren't finishing" into "sixty percent stop at the photo upload."
The share of people who finish a given step. Worth quoting with both numbers, since 40% of five people isn't much.
Retention is the share who come back. Churn is the share who leave, usually measured monthly.
In practiceSign-ups tell you how the marketing is doing. Retention tells you how the product is doing.
A group who joined in the same period, tracked separately over time.
In practiceThe fair way to see whether things are improving: compare people who joined in March against people who joined in June, instead of averaging everyone together.
Recording what people do in the product, so questions get answered with counts instead of impressions.
In practiceIt only captures what someone set up in advance. "We don't have that number" usually means nobody asked for it yet.
The one number picked to stand for whether the product is working, that everything else answers to.
Showing two versions to two random halves of your users and keeping whichever does better.
In practiceNeeds real volume to say anything. With a few hundred people you're mostly measuring noise.
The point where people want it enough that they come looking for it and get annoyed when it isn't there.
In practiceLoosely defined and heavily used. The practical version: are people using it without being reminded, and telling other people about it.
A reasonable thing to ask anyone writing software for you right now, and how we'd answer it.
If code gets written faster now, why does a project still cost what it costs?
Because the writing was never the expensive part. Working out what should exist is, and that hasn't changed much. Faster tools mostly moved the cost onto the deciding.
Anyone can put a screen together in an afternoon now. That isn't really what you're paying for. What moves a project is time spent in your actual operation, on the floor or in the numbers, until the problem is clear enough to say in a sentence. Once it's clear, the software part is usually small.
Projects run long because that part got skipped, not because the typing was slow. So the honest measure isn't how quickly a screen shows up. It's how quickly the problem stopped costing you money.
The technology ends up being a byproduct. The work is figuring out which twenty minutes of someone's day you can give back.
Take the vocabulary on this page away and most business systems are the same three things. Somewhere the records live, an agreed way for other software to read and write them, and a screen or a sensor where someone touches them. A dispatch board, a quoting tool, a customer portal, a reader on a line. Same shape underneath.
Which is why the unglamorous parts matter more than the impressive ones. Get the records right and you can change the screens whenever you like. Get them wrong and a nice screen doesn't help much.
The work we find most interesting sits right at that seam. Material that has to move, a machine that has to run, someone on a truck who needs an answer now. A lot of it is still handled on paper, over the phone, or in somebody's head.
It isn't that those problems are hard. Mostly nobody has gotten to them yet. And every one of them is that same shape: some records, an agreed way to read and write them, and a screen in front of the right person at the right time.
"We use AI, so it's faster" is true, and very easy to oversell. It speeds up producing things. It doesn't speed up understanding how your business runs, finding your first customers, or deciding what the product should promise. If someone tells you it does, that's a good moment to ask more questions.
Thirty-minute discovery call. No deck. We scope one bounded piece of work, agree on a price, and start within two weeks.