Working with an external client is not the same as a group project with your classmates or an assignment supervised by your professor. Inside the university, the relationship is already established before you start: your classmates and instructors know you, and the course structure holds things together. With a client, none of that exists yet. You begin as strangers, and the working relationship has to be built as you go — on trust, respect, and clear communication.
Capstone projects rarely fail because the project was too hard. They fail because the client expected one thing and the team built another — and that gap almost always opens up through poor communication, one unasked question and one unconfirmed assumption at a time.
This page is about how to behave in that relationship. Professionalism is worth up to 10% of your grade through the Client and Instructor Evaluations component, assessed individually on four criteria: responsiveness, reliability at meetings, quality of communication, and whether you did what you said you would do. It also shows up in the participation factor and, indirectly, in every milestone — because teams that communicate badly build the wrong thing.
1. Make the First Meeting In Person¶
Book the first meeting in person wherever geography allows. It is not about the agenda; you could cover the same agenda on Teams in half the time. It is about rapport. Clients invest more in people they have met, they interrupt less over video once they know your faces, and they are far more forgiving of a bad week later in the term if the relationship started with a handshake.
Offer to travel to them. Their office, their lab, their shop floor — being in the environment your software will run in teaches you things no requirements document contains. If the client is genuinely remote, make the first meeting video-on for everyone, and make sure every team member speaks.
First meeting
✅ Do | ❌ Don’t |
|---|---|
“We’d like to come to you for the first meeting — would Thursday afternoon at your office work? All four of us will be there.” | “Here’s a Teams link for Thursday, whoever can make it.” |
Arrive as a team, dressed a step above how you’d attend class, with a printed or shared agenda. | Two of you show up, one joins from a phone in a car, one never explains their absence. |
Ask for a tour, or to watch someone do the task your project will change. | Stay in the meeting room and treat the visit as a formality before the “real” work. |
Learn and use everyone’s name and role; note who the decision-maker is. | Address only the most technical person present and ignore the rest. |
2. Be On Time — It Is Being Marked¶
Punctuality is the cheapest signal of competence available to you, and lateness is the cheapest signal of the opposite. A client cannot see how well you refactored something. They can see that you were seven minutes late for the third time.
On time means present and ready at the start time — not arriving at the start time, not joining and then fumbling with screen sharing. Aim to be there five minutes early. This applies to client meetings, weekly supervision meetings, and milestone reviews equally.
Punctuality
✅ Do | ❌ Don’t |
|---|---|
Join five minutes early; test screen sharing before the client arrives. | Join at the exact minute and spend the first four minutes on “can you see my screen?” |
When something genuinely goes wrong: “I’m stuck in traffic and will be 10 minutes late — please start without me, Priya will take notes.” Sent before the start time. | Arrive 10 minutes late and say “sorry, traffic” with no advance message. |
End on time. If you need more, ask: “We have five minutes left and two items — shall we book a follow-up rather than run over?” | Let the meeting run 25 minutes past because you hadn’t prioritised the agenda. |
Reschedule at least 24 hours ahead when a conflict is known. | Cancel an hour before, or worse, no-show and apologise afterwards. |
3. Communicate as a Team, Not as Individuals¶
From the client’s point of view there is one project team, not four students. They should never have to wonder who to contact, never receive contradictory answers from two of you, and never be the mechanism by which your team shares information internally.
CC every team member on every email exchange with the client, without exception. Reply-all is the default. This is not bureaucracy: it means any team member can pick up a thread when someone is ill, it keeps a single searchable record of every commitment made, and it prevents the situation where one student has quietly agreed to a scope change nobody else knows about.
Nominate a primary point of contact for scheduling and routine correspondence, but make clear that the whole team is reachable and reading.
Team communication
✅ Do | ❌ Don’t |
|---|---|
Every email to the client CCs all teammates. Reply-all every time, even for “thanks, received.” | DM the client individually, then relay the answer to your team in chat — or not at all. |
“Our team has reviewed this and we recommend…” | “I think we should… but I’m not sure what the others want to do.” |
One person schedules, but the signature reads Team 4 — Alex, Priya, Sam, Dana. | Four different students email the client on four different days about the same question. |
Disagree internally first, arrive at the meeting with an agreed position, and present it as one. | Argue with a teammate in front of the client about which framework to use. |
When you must speak for yourself: “Speaking for my own component here — the others may see the integration differently.” | Commit the team to two weeks of extra work without asking them. |
4. Be Transparent — About Bad News, Options, and Risks¶
Transparency is not about volunteering every detail. It is about the client never being surprised by something you already knew. Slipping schedules, a component that turned out harder than expected, a teammate who has gone quiet — these get worse when hidden, and they are always discovered eventually.
Bad news delivered early is a manageable problem. The same news delivered at the demo is a broken commitment. Clients are generally understanding about student teams hitting difficulty; they are not understanding about being kept in the dark.
The same applies to your supervisor. A blocker raised at a supervision meeting can usually be solved; the same blocker surfacing for the first time at a milestone review usually cannot.
The same honesty applies when there is a choice to make. Clients hire you for judgement, not just labour — so present the realistic options with what each one costs, what it gives up, and what could go wrong, then make a recommendation and say why. Presenting one option as if it were the only option is a way of making the client’s decision for them without telling them you did. Own the downsides of your own preferred option: a team that only ever describes the upside of its own choice is a team whose assessments cannot be trusted.
Be specific about risk. “There’s some risk” is useless. “If their API rate-limits us, the sync could take four hours instead of ten minutes; we’d find that out in week 8, and the fallback is a nightly batch job” is something a client can act on.
Transparency
✅ Do | ❌ Don’t |
|---|---|
“The OCR accuracy is well below what we hoped. Here are three options and what each costs us — we’d like your view before we commit.” | Keep working and hope it improves before anyone asks. |
“Two of us have midterms the week of Oct 12, so expect slower progress that week. We’ve adjusted the plan and here it is.” | Go silent for two weeks and resurface with excuses. |
Send a short weekly status note: done / next / blocked. Three bullets each. | Only contact the client when you need something. |
“We’re not confident we can deliver the mobile version by December. We’d rather tell you now than in November.” | Promise everything, then quietly drop features and hope they aren’t noticed. |
Say plainly when you don’t know: “We don’t know yet — we’ll investigate and come back to you by Friday.” Then come back by Friday. | Improvise a confident answer that turns out to be wrong. |
Options and risk
✅ Do | ❌ Don’t |
|---|---|
“Two options. A: faster to build, but you’d be tied to one vendor. B: three weeks longer, but portable. We recommend A because the term is short — and we’d flag the lock-in as a real cost.” | “We’re going to use Firebase.” |
“The main risk is that we can’t get test data until October. If that slips past the 15th, Milestone 3 is at risk, and we’d descope the reporting module first.” | “It should be fine.” |
Keep a risk register and review it with the client at each milestone. | Mention risk once at kickoff and never again. |
“None of us have used this framework before. It’s the right fit, but we’d budget a week to learn it.” | Hide inexperience and absorb the delay silently. |
Distinguish clearly: “This is a fact” vs “This is our estimate” vs “This is a guess.” | Present estimates with the confidence of facts. |
5. Take Careful Notes, and Get It In Writing¶
Assign a notetaker for every client meeting, and rotate the role so the burden is shared and everyone learns to do it. Capture decisions, action items with owners and dates, open questions, and anything the client said about their domain that you didn’t already know.
Within 24 hours, send a short summary email to the client, CCing your team. This does two things: it gives everyone one shared version of what was agreed, and it gives the client a low-effort chance to correct a misunderstanding while it is still cheap. “That’s not quite what I meant” three days after a meeting is a gift. The same sentence at Milestone 3 is a disaster.
Keep these notes in your repository. They become the traceability evidence for Milestone 1 requirements and material for your final report.
The same habit extends beyond meeting summaries, and it is the habit that saves projects. Verbal agreements are remembered differently by different people, in good faith, and a capstone runs long enough for that to matter. Anything that changes scope, deadlines, access, data handling, or money goes in writing — always. Not as a legal manoeuvre, but because it protects the client as much as it protects you.
Written confirmation does not need to be formal. A short email, CCing your team, is enough:
Hi Maria — following up on today’s call to confirm: we’ll drop the SMS notifications from this term’s scope and add the CSV export in their place. Milestone 3 on Nov 5 will show the export working. Please let us know by Friday if that doesn’t match your understanding. Thanks — Team 4 (Alex, Priya, Sam, Dana)
Notes and follow-up
✅ Do | ❌ Don’t |
|---|---|
A designated notetaker each meeting, with notes committed to the repo the same day. | Everyone assumes someone else is writing it down. |
Follow-up email: Decisions (3 bullets) · Actions (owner + date) · Open questions · “Please correct anything that doesn’t match your understanding.” | “Great meeting, thanks!” and nothing else. |
“To confirm: reports export to CSV only for now, PDF is out of scope for this term. Is that right?” | Remember it differently from your teammate and discover the gap in November. |
Record the client’s own terminology and use it back to them. | Silently rename their domain concepts to whatever you find more natural. |
Written confirmation
✅ Do | ❌ Don’t |
|---|---|
Confirm every scope change by email, CCing your team and, where it matters, your supervisor. | Accept “sure, add that in” in a hallway conversation and start building. |
“Just to have it in writing: you’re happy for us to use the anonymised extract on our own machines. Could you reply confirming?” | Rely on a verbal yes for anything touching data or IP. |
Escalate to your supervisor when a request seems outside the agreement, before agreeing to it. | Agree because the client seemed confident and you didn’t want to push back. |
Keep the thread. Don’t start a new email chain for a continuing topic. | Move a scope discussion into a chat app that nobody can search in December. |
Where the client prefers verbal, still send the summary afterwards: “To confirm what we discussed…” | Skip the summary because “they already know.” |
6. Ask Clarifying Questions and Assume Nothing¶
You have the technical skills. You do not have the domain knowledge — and the domain knowledge is where the requirements actually live. The client knows how their intake process works, which of the fifteen fields on that form anyone actually reads, and why the Thursday report exists. You will not deduce any of that from a codebase.
Every assumption you make instead of asking is a risk you have taken on the client’s behalf without telling them. The most expensive failures in capstone projects are not bugs; they are teams building a technically excellent solution to a problem the client did not have.
Treat this as a learning opportunity rather than an interrogation. Genuine curiosity about someone’s work is disarming, and clients enjoy explaining their domain to people who are actually interested.
Questions and assumptions
✅ Do | ❌ Don’t |
|---|---|
“Can you walk me through how you do this today, step by step? I’d like to see the current spreadsheet.” | Assume the current process is obvious and design a replacement for it. |
“When you say ‘urgent case’, what makes a case urgent? Who decides?” | Assume ‘urgent’ means a boolean flag you invent. |
“Roughly how many records per month? And how far back does the history go?” | Assume it’s small enough to load in memory. Discover in November that it isn’t. |
“Sorry, what does triage code mean in your context? I want to make sure I use it correctly.” | Nod along at unfamiliar terms and look them up later, guessing wrong. |
“Who else uses this? Would anyone outside your team touch the system?” | Design for the one person in the room and miss three other user groups. |
Ask the “obvious” question. Nobody has ever thought less of a team for confirming a detail. | Stay quiet to look competent, then build on a bad guess. |
7. Explain Technical Things in Plain Language¶
Your client is not a computing scientist. That is precisely why they need you. Your job is to make technical decisions understandable enough that a non-specialist can make an informed choice about their own project.
Jargon in a client meeting is not a display of expertise — it is a failure of communication, and often a way of avoiding scrutiny. Translate. Talk about what the client will experience, what it costs, and what it rules out. Use analogies from their world. Then check that you were understood, and check for agreement, not just comprehension.
Watch for the polite nod. Many clients will not say “I don’t follow” — you have to make it safe for them to say it.
Explaining technical work
✅ Do | ❌ Don’t |
|---|---|
“We’d store the data in a way that makes searching fast but adding new kinds of information slower. Given you rarely change the form, we think that’s the right trade — does that match how you work?” | “We’ll use a normalised relational schema with a B-tree index on the composite key.” |
“This will take about three weeks and means the report loads in under a second instead of thirty.” | “We’re going to refactor the persistence layer.” |
“Does that make sense, or should I explain it a different way?” — then pause and actually wait. | “Any questions?” said while already advancing to the next slide. |
“So we’re agreed we go with option B, accepting the slower import?” and get an explicit yes. | Treat silence as approval. |
Draw it. One diagram on a whiteboard beats three paragraphs. | Read a wall of text off a slide. |
Use their vocabulary: “cases”, “clients”, “intakes” — not “records”, “entities”, “rows”. | Force your data model’s names into the conversation. |
8. Run a Client Meeting, Not a Code Review¶
A client meeting is not a screen share of your IDE. Opening VS Code and scrolling through files tells the client nothing they can evaluate, and it signals that you have not thought about what they need from the meeting. They cannot assess your code. They can assess whether the thing does what they asked for.
Show working software from the user’s point of view, or show a diagram. Prepare and rehearse. If a demo could fail, have a recording or screenshots as a fallback.
Meeting conduct
✅ Do | ❌ Don’t |
|---|---|
Send an agenda 24 hours ahead: what you’ll show, what you need decided. | Turn up with no plan and improvise. |
Demo the running application doing a task the client recognises, with realistic data. | Scroll through source files explaining your folder structure. |
“The import now handles the March file. Here it is running.” Ninety seconds, then stop. | A twenty-minute unrehearsed tour that ends in a stack trace. |
Bring decisions to them: “We need your call on two things today.” | Use the whole slot on a progress narrative and ask nothing. |
Have a fallback recording or screenshots ready. | Debug live in front of the client for ten minutes. |
Use anonymised or synthetic data in demos. | Demo with real client records on a shared screen. |
9. Take Data, Confidentiality, and Agreements Seriously¶
This is the section where mistakes stop being academic and start having legal consequences — for the client, for the university, and potentially for you personally. Client data may be covered by British Columbia’s FIPPA or PIPA, by health or financial regulation, or by contractual obligations the client has to their customers. A breach caused by a student team is still a breach.
The safest working assumption: you do not need real data. Ask for anonymised or synthetic data, and only accept real data if the client insists and the agreement allows it. If you do hold real data, hold as little as possible, for as short a time as possible, in the place the agreement specifies.
Be especially careful with AI tools. Pasting client data into a chatbot is a disclosure to a third party. Check what your client agreement and the course’s generative AI policy permit before any client material goes near a model, and assume the answer is no unless it is written down.
Data handling
✅ Do | ❌ Don’t |
|---|---|
“Could you provide anonymised or synthetic sample data? We’d rather not hold real personal information.” | Accept a spreadsheet of real customer records because it’s easier. |
Keep credentials in environment variables or a secrets manager; keep the repo private. | Commit an API key, connection string, or |
Store client data only where the agreement allows, and delete it at handover. | Keep a copy of the production dump on a personal laptop after the term ends. |
Use anonymised data in demos, screenshots, slides, and the final report. | Screenshot a real record into a milestone presentation given to an audience. |
Ask before any client material goes into an AI tool; get the answer in writing. | Paste a client document into a chatbot to summarise it. |
Report a suspected breach to your supervisor and the client immediately, the same day. | Quietly delete the file and hope nobody noticed. Concealment is far worse than the incident. |
Ask about regulated data early: “Does any of this fall under health, financial, or student privacy rules?” | Assume that because it’s a student project, normal rules are relaxed. They are not. |
Read the agreements before you sign¶
The rules above are not only good practice — most of them are written down somewhere you have signed. You will sign a confidentiality agreement covering client material, and your project agreement will state IP terms. These are binding legal documents. Signing one you have not read is a bad habit to establish in the first professional contract of your career.
Read it. Know specifically: what counts as confidential, how long the obligation lasts, who owns what you build, whether you may show the work in a portfolio or on GitHub, and what you must do with the material at the end. If you want to use the project in a job search — and you probably will — sort the portfolio permission out in writing at the start of the term, when it is easy, rather than in December when it is not.
If anything is unclear or uncomfortable, raise it with your supervisor in Week 1. As the syllabus states, such requests are legitimate and carry no penalty, and an alternative project can be arranged.
Agreements
✅ Do | ❌ Don’t |
|---|---|
Read every clause before signing. Ask your supervisor about anything you don’t understand. | Sign because everyone else on the team already did. |
Keep your own copy of the signed agreement and re-read it before publishing anything. | Sign it, never look at it again, and rely on memory. |
“Before we start — would you be comfortable with us showing this work in a portfolio after the course? We’d like to confirm in writing now.” Then follow whatever the answer is. | Push the repo public in January because the course is over. |
Follow the agreement’s rules on hosting, access, and third-party services even when inconvenient. | Spin up a personal cloud account for client data because it was quicker. |
Assume the client owns what you build unless the agreement says otherwise. | Assume you own your code because you typed it. |
Do the deletion and handover steps the agreement requires at the end of term. | Let the obligations lapse in your mind the moment grades are posted. |
10. Be careful with using GenAI to Write Email¶
It is best practice to write email yourself, rather than relying on AI tools, because it preserves your unique voice and who you are as a person.
However, many of you might draft client email with an AI assistant. That is not forbidden — see the course’s generative AI policy for what must be disclosed, and remember from §9 that client material must not go into the tool in the first place. But be aware of what these tools do to your writing. Left unedited, they produce email that is three times longer than it needs to be, opens with a paragraph of throat-clearing, restates the client’s own question back to them, and closes with enthusiasm nobody feels. Clients read it as filler, and after two or three of them they start reading your email less carefully — which is expensive when the fourth one contains something that matters.
The problem is not that it sounds robotic. It is that length is a cost you are imposing on someone else. A busy client scanning their phone between meetings wants the decision, the date, and what you need from them. Padding buries all three.
Treat AI output as a first draft you are obliged to cut. Delete the opening pleasantry, delete any sentence that restates what the client already knows, delete every intensifier, and check that the ask is in the first two lines. If what remains is four sentences, send four sentences. Then read it aloud — if it doesn’t sound like something you’d say to the client’s face, rewrite it in your own words.
Here is a real example.
AI-generated, unedited:
Dear Maria,
I hope this email finds you well. I wanted to take a moment to reach out to you regarding an important matter that has recently come to our attention as we continue to make progress on the data import functionality for your project.
During the course of our development work this week, our team conducted a thorough analysis of the sample export files that you kindly provided to us, and we discovered an interesting discrepancy that we believe warrants your input. Specifically, we noticed that the date fields within these files appear to be formatted inconsistently — some records seem to use a day-month-year convention while others appear to follow a month-day-year convention. As you can no doubt appreciate, this is the kind of subtle issue that could potentially have significant downstream implications for the accuracy and reliability of the reporting features we are building.
We would therefore be extremely grateful if you could possibly find the time to let us know which of these two formats should be considered authoritative for our purposes. Your guidance on this matter would be invaluable in helping us to ensure that we are moving forward in the right direction and building something that truly meets your needs.
Please don’t hesitate to reach out if you have any questions whatsoever or if there is anything further we can clarify. We really appreciate your continued partnership and look forward to hearing back from you at your earliest convenience.
Warm regards, Team 4
Human, edited down:
Hi Maria,
We noticed the sample export mixes two date formats: some rows are DD-MM-YYYY, others MM-DD-YYYY. Which one is correct? If it’s genuinely both, we’ll need a rule for telling them apart.
Thanks — Team 4 (Alex, Priya, Sam, Dana)
The second is about 40 words against 250. It states the problem, asks one question, and stops. It is also the only one of the two that a client can act on from a phone.
Quick Reference¶
Before every client meeting
Agenda sent at least 24 hours ahead, all teammates CC’d
You know the two or three decisions you need from them
The demo is rehearsed and a fallback exists
Notetaker assigned
Any data on screen is anonymised
During
Present and ready five minutes early
One team, one position; disagreements resolved beforehand
Plain language, their vocabulary, checked for understanding
Questions asked rather than assumptions made
Options presented with costs, downsides, and risks
Finish on time
After, within 24 hours
Summary email: decisions, actions with owners and dates, open questions
Explicit invitation to correct anything that doesn’t match
Notes committed to the repository
Anything that changed scope confirmed in writing
Always
Reply-all on client email
Ask in the first two lines; cut AI drafts by half before sending
Bad news early, never late
Nothing confidential leaves the agreed boundary
If in doubt, get it in writing