You have found a partner to build your website or app, the kickoff call went well, and everybody is excited. Before a single screen is designed, though, there is a ten-minute job that will save you weeks of friction later: a project glossary checklist. In plain terms, it is a short list of the words you and your partner will lean on most, each with one agreed meaning and one person who looks after it. Most project fights are not really about effort or skill. They are about two smart people using one word and picturing two different things. Let’s fix that before it starts.
Why a project glossary checklist beats a long contract
Contracts are written to settle disputes after they happen. A glossary is written so the dispute never happens. Think of it as a friendly agreement about vocabulary: when we say “launch,” here is what we both mean. It does not replace your paperwork; it makes the paperwork readable for everyone on the team, including the people who will never open the contract.
If you are new to working with a digital agency, it helps to first get a feel for how a typical engagement unfolds. Our walkthrough of what the first months with a digital services partner usually look like gives you the big picture, and this checklist plugs into its very first stage.
The checklist: words to define before work begins
Go through these one by one. Tick each item only when both sides have agreed on a written sentence. Skip any that genuinely do not apply to your project, and add your own.
“Launch” or “go-live”
Does launch mean the site is visible on your domain, or that it is visible and announced to customers, or that it is visible, announced and has run smoothly for a week? Pick one. A good sentence sounds like: “Launch is the day the new site answers on our main domain and the old one redirects to it.”
“Done” for a single task
Separate from launch, you need a meaning for when an individual piece of work is finished. Many teams use something like: “A task is done when it works on desktop and phone, the client has seen it, and nothing on it is marked as a known problem.” Without this, tasks bounce back and forth forever.
“Revision”
Quotes often promise a number of revisions. What counts as one? Is moving a button a revision, or only a round of feedback sent in one go? Agree that a revision is one consolidated set of comments delivered together, and that new ideas outside the original page are a change request instead.
“Change request”
Speaking of which, define it. Something like: “Anything that adds a page, a feature or an integration not listed in the original plan.” That sentence alone prevents the slow creep that turns a small project into an endless one.
“Mobile-friendly”
Everybody says it; few people mean the same thing. Does it mean the layout rearranges on a phone? That every feature works on a phone? That it works on the two or three phone models your customers actually use? Write the version you care about.
“Support”
After handover, what does support cover? Bug fixes only? Content updates? Hosting problems? And for how long? Many unhappy client relationships start right here, a few weeks after launch, when one side assumed support meant “help with anything” and the other meant “fixing our own mistakes.”
“Response time”
Is that the time until someone replies, or the time until the problem is solved? Is it counted in working hours or calendar hours? A reply in two hours is very different from a fix in two hours, so name the one you are agreeing to.
“Content ready”
Projects stall when the client believes content is ready and the builder believes it is not. Ready might mean final text approved by the owner, images sized and licensed, and product details checked. Write that down, because it decides who is waiting for whom.
“Handover”
What do you receive at the end? Logins, source files, a short guide, a recorded walkthrough? Agreeing on handover early means nobody is surprised when the final invoice arrives.
What if you cannot agree on a meaning?
Sometimes the conversation reveals a real difference rather than a misunderstanding. You want support to include small content edits; your partner prices support as bug fixes only. That is good news, honestly, because you found it on day one instead of month three. Talk it through, settle on a version, and if the bigger scope costs more, decide now whether it is worth paying for. A disagreement discovered early is a negotiation. The same disagreement discovered late is a grudge. Either way, write down whatever you land on so that nobody has to rely on memory when the question returns.
Now give every definition an owner
A definition without an owner slowly goes stale. Next to each ticked item, write a name. Usually the client owns business meanings, such as what counts as content ready, and the builder owns technical ones, such as what mobile-friendly covers. The owner is the only person who can change the wording, and when they do, they tell everyone and date the change. That one rule keeps old and new meanings from mixing.
Tips to make your glossary actually get used
- Stay short. Should the list spill beyond a single sheet, you are writing a manual. Trim back to the words that drive decisions.
- Use everyday language. If a non-technical co-founder cannot understand an entry, rewrite it. Our guide to digital services in simple, jargon-free terms is a nice model for that tone.
- Pin it where conversations happen. Top of the shared project board, the first message in the group chat, or the cover page of the weekly update.
- Read it aloud at kickoff. It takes five minutes, and you will be amazed how often someone says, “Oh, I thought that meant something else.”
- Revisit it at milestones. Not to inspect anyone, simply to ask whether any word has started to wobble.
A quick example
Imagine a bakery owner, Fatima, building her first online ordering site. Her glossary ended up with six entries. The most valuable was “order confirmed,” which she defined as “the customer has paid and received an email with a pickup time.” Her developer had originally treated an order as confirmed the moment the button was pressed, even if payment failed. Catching that difference on a kickoff call, rather than on a busy Saturday morning with angry customers, was worth the whole exercise. If you are at a similar stage, our roadmap for testing and growing a first digital product pairs well with this kind of early clarity.
Borrowing from teams who do this every day
Data teams live with this problem constantly, because a word like “order” or “customer” may be counted differently in three different systems. Practitioners who want to get better at it often study data quality and governance through programmes like DataOpsSchool’s training and consulting for data teams, where agreed meanings are treated as the bedrock of trustworthy numbers. You can apply the same mindset to a ten-page website.
Your printable checklist summary
- Launch or go-live, defined in one sentence
- Done for a single task
- Revision, and how many
- Change request
- Mobile-friendly, in your terms
- Support scope and duration
- Response time versus resolution time
- Content ready
- Handover contents
- An owner’s name beside every line
That is it. One page, one meeting, a handful of plain sentences. It is the least glamorous part of any project and quite possibly the most useful. Do it once, keep it visible, and you will spend your energy building something great instead of arguing about what everybody meant.
