At some point in this course you stop building for yourself and start building for a named person: a teacher, a coach, a librarian, a caretaker, someone at a local organisation. That person is your client, and the interview is where the project is really decided. Twenty careful minutes here save three weeks of building the wrong thing — which is the most common way student projects fail, and one of the most common ways professional ones do.
Ask permission first
Approach in person or by a short message, and be plain about what you are asking for. You are a student, this is a school project, you want about twenty minutes, and they may say no.
Consent is not a formality
Three things need an explicit yes, and you ask for them in words: may I take notes?, may I use your name in what I hand in?, and may I show this to my class? “No” to any of them is a complete answer, and the project still works — a client can be “a coach at this school” in every document you write. Ask again before anything becomes public, because agreeing to a conversation is not agreeing to a presentation.
Listen for the problem behind the request
Clients rarely describe a problem. They describe the solution they have already imagined, and it is usually a version of something they have seen elsewhere. Your job is to get underneath it.
| They say | You ask |
|---|---|
| ”I need an app." | "Walk me through how you do it now." |
| "It should have a database." | "What are you trying to look up, and how often?" |
| "It takes forever." | "Which part takes the longest? Where does it go wrong?" |
| "Everyone else uses X." | "What would you keep from X, and what annoys you?” |
Ask what happens now, step by step, including the boring parts. Ask what goes wrong and how often. Ask what they do when it goes wrong. And listen for the sentence they say twice — repetition is how people signal what actually hurts. The warm-up What Would You Ask is practice for precisely this moment.
Be honest about scope
You have a handful of weeks and a Grade 11 toolkit. Say so. The question that keeps a project honest is not “what would be amazing?” but “what would actually save you time?” — and the answer is almost always smaller than either of you expected.
- Offer to solve one thing completely rather than four things partially. A tool somebody uses beats a demo nobody does.
- Name what you will not build, out loud, in the meeting.
- Never promise a feature you have not built before, unless you also say it is uncertain.
- If they ask for something impossible, say “I do not think I can do that in the time I have — could this help instead?”
Handle their information carefully
Real clients come with real data: names, schedules, contact details, sometimes information about other people who never met you.
- Collect only what the program genuinely needs. If the tool works with initials, do not ask for full names.
- Never gather information about third parties — students, members, patrons — without the client’s explicit agreement about what is reasonable to hold.
- Test with made-up data wherever you can. Your test file does not need anybody’s real phone number.
- Nothing real goes in a screenshot, a slide, or a public repository. Sharing What You Build covers the publishing side of this.
Write it back and follow up
Within a day, send a short summary: the problem in their words, what you agreed to build, what you agreed not to build, and one question you forgot to ask. Two things happen. They correct you — cheaply, now, in writing — and they see that you were listening.
- Problem stated in the client’s own words, not yours
- The one thing the tool must do, written in a single sentence
- What is out of scope, named explicitly
- Permissions recorded: notes, name, presentation
- A date for showing them a first rough version
Then keep showing up. One short check-in with something half-working teaches you more than a month of guessing, and it is how The Community App ends with a handover somebody can actually use.