At a glance
Solo, or pairs with two clients’ agreement · launched at the end of Unit 3 and running through all of Unit 4 across fifteen named working days · a working app, a tested handover, and a real person who keeps using it · the culminating project of this course
What you are making
An app for a real person in the school or the local community, who has a modest problem you agreed on together, built with them and handed over so that they can use it without you in the room.
Your client is a teacher, a coach, a librarian, a caretaker, an office administrator, a club organiser, somebody at a neighbourhood organisation, a family member who runs a small business. They are a person you can talk to more than once. They are not “students in general”, not “the school”, and not hypothetical.
The bar is not cleverness. The bar is this: a month after you hand it over, is it still being used? Everything below exists to make that question answerable in your favour.
Finding your client
Ask three people what part of their week they would happily never do again. Listen for the chore that is repeated, small, and currently done by hand or in somebody’s head — a tally, a list, a lookup, a conversion, a schedule, a check.
Ask for twenty minutes and mean it. Bring the questions you drilled in What Would You Ask, run the interview the way Interviewing Your Client describes, and take notes you would be comfortable showing them.
Then write the problem in their words, one sentence, and read it back. If they correct you, you have learned the most valuable thing you will learn this month. Nothing else in this project proceeds until they agree that sentence is true.
Consent and privacy
This part is not paperwork. It is the craft.
- Consent to be named. Ask whether you may name them in your documentation and at the launch. If they say no, they are “a coach” or “a library assistant” in everything you write, permanently.
- Consent for the work. They agree to one interview, one testing session, and the handover. Tell them what each will cost them in minutes, and keep to it.
- Collect nothing you do not need. If your app can do its job with initials instead of names, use initials. If it can work with a count instead of a list of people, use the count. Every field you do not store is a risk you did not create.
- Never collect anyone’s contact details, marks, health information, financial details, or anything about a third party who is not in the conversation. If the chore seems to require it, change the design, not the rule.
- Say where the data lives. Your app writes files. Your client must be told what is in them, where they are, and how to delete them.
- They can stop. At any point, including after the handover. If they ask you to delete their data, you delete it and confirm.
Scope honesty
A small thing that works and gets used beats an ambitious thing that does not, and that is not a consolation prize — it is the assessed position of this course.
So: name your core — the single thing that, if it worked and nothing else did, would still be worth your client’s time. Build that first, finish it, and only then consider anything else. Keep a “deliberately not doing” list from the first day, and show it at the design review. Every item on that list is a decision you can defend; every item quietly attempted and abandoned is a mess you cannot.
If you find yourself hoping to finish something the night before, the scope was wrong three weeks earlier. Cut it now, tell your client what they will and will not be getting, and finish the smaller thing well.
Milestones
These are checked in class, on the day named. Nothing here is a final-week scramble; a project that arrives at Unit 4, Day 5 without a tested core is a project I will help you cut down, not a project you should try to rescue by staying up.
- Unit 3, Day 16 — launched. Three people asked, and two possible clients with the chore each described.
- Unit 3, Day 17 — client and problem approved. One named client, the problem in their words, their consent recorded, and my sign-off in writing.
- Unit 4, Day 2 — designed for them. Every screen your client will see, on paper: each prompt, each message, each way out. Plus the list of what your app must never ask for.
- Unit 4, Day 5 — core runs, design reviewed. The core feature works end to end, badly is fine, and you have shown your screens and your “deliberately not doing” list to two classmates.
- Unit 4, Day 13 — tested with the real user. Beside them, not for them. Written notes on everything they did that you did not expect.
- Unit 4, Day 14 — bugs triaged. Every problem from the client test either fixed, or written down honestly as a known limit.
- Unit 4, Day 17 — documented and handed over. The handover package below is complete, and the project is submitted.
- Unit 4, Day 18 — presented. Your client runs it in front of the room at Launch Day, and takes it home.
What a defensible handover contains
“Handed over” means your client can use it, next month, without you. That takes more than a file:
- The program itself, in a folder with a name that means something to them, on a machine or drive they control — not only on yours.
- A one-page guide in their language, not yours: what it is for, how to start it, what it will ask, what it gives back, and one worked example with real-looking values.
- What to do when it goes wrong — the two or three failures you know are possible, what they look like, and what to do about each.
- The known-limits list. What it does not do, what it will never do, and what would happen if their situation changed. Honest, plain, unashamed.
- Where the data lives, what is in it, how to back it up, and how to delete it.
- How to get it changed: who wrote it, when, what it is written in, and what a future student would need to know to modify it — which is what Writing Code Others Can Read has been preparing you for, inside the code itself.
- A follow-up promise you can keep. One check-in, at a time you name. Then keep it.
How this is assessed
Per How Marks Work, the working periods, the milestones, and the trail in your Code Journal all count — this project is assessed across five weeks, not on the last day. Expect a journal entry at every milestone; the entry after the client test is the single most important piece of writing you will do in this course, because it records what a real person did with something you built.
The technical work is judged on whether it holds up in somebody else’s hands: Testing and Debugging standards apply, the design decisions come from Decomposition and Design, and the process language is The Software Development Process.
Success criteria
| Quality | What it looks like in your project |
|---|---|
| A real client | Named or deliberately anonymised, interviewed, consenting |
| Their problem, their words | The agreed sentence is theirs, and they confirmed it |
| Honest scope | A finished core plus a defended “not doing” list |
| Designed for a person | Prompts, messages, and errors written with dignity |
| Tested with them | Notes from the session, and changes that came from it |
| Survives bad input | The failures found in the hunt are handled or declared |
| Defensible handover | All seven pieces above, in their hands |
| Privacy as craft | Nothing collected that was not needed and agreed |
Reflect
Read your Code Journal from the day you found your client to the day you handed over, and answer this in your Final Reflection: what did you build that they did not need, and when could you have known? Then the question this whole course has been circling, from Who Is This For onward — what does it change about your programming to know that somebody is going to open it on a Tuesday when you are not there?
If you cannot find a client
You are looking too far away. Within a hundred metres of this room there is somebody keeping a tally on paper, retyping the same list every week, counting something twice because they do not trust the first count, or converting between two units in their head every single day. Ask the person who runs a club, the person who orders supplies, the person who does the schedule. Ask three of them. One will say something like “well, there is this one annoying thing” — and that sentence is your project. If you are genuinely stuck by the approval deadline, come to me: I keep a list of people in this building who have already said yes.
Curriculum connection
B4.1
describe the phases (i.e., problem definition, analysis, design, writing code, testing, implementation, maintenance), milestones (e.g., date of completion of program specification), and products (e.g., specification, flow chart, program, documentation, bug reports) of a software development life cycle;
Link to original
B4.2
use a variety of techniques (e.g., dialogue, questionnaires, surveys, research) to clarify program specifications;
Link to original
B2.5
design user-friendly software interfaces (e.g., prompts, messages, screens, forms).
Link to original
B4.6
communicate information about the status of a project (e.g., milestones, work completed, work outstanding) effectively in writing throughout the project.
Link to original