Webbo3 Level 2 · JavaScript Development · Day 20 of 20
Project 4: Work Like a Developer
A client brief, a team of five, and everything from the last four weeks in one build. The closest thing to a real sprint we can give you.
By the end of today you can
- Take a vague brief from a non-technical client and turn it into scoped work
- Break that work into issues and run it through branches and pull requests
- Build, review, test and deploy as a team
- Present to the client rather than to your instructor
Project 2 asked whether five of you could solve a problem together. This one asks whether you can work for somebody. The difference is that you no longer get to choose what matters: a client does, and they will describe what they want in words that are not requirements.
The brief
Project 4 · Groups of five · The full week
A small business currently manages customer requests through WhatsApp and a spreadsheet. Messages get missed, two people reply to the same customer, and nobody can say how many requests are outstanding. Build a web application that helps them manage requests.
That is what a real brief looks like: a description of a problem by somebody who is not going to tell you what to build. Notice what it does not say. It does not say what a request contains, who the users are, what "managed" means, or what happens when a request is finished. Those gaps are the work.
Your instructor is playing the client
You may ask them anything, and they will answer as the business owner would: in business terms, sometimes vaguely, occasionally changing their mind. Booking that conversation is the first task, and teams that skip it build the wrong thing on day one.
1. Before any code: understand and scope
The questions to actually ask
- Walk me through the last request you handled, from the message arriving to it being finished.
- Who touches a request? Just you, or staff as well?
- What is in a request? What do you need to know about it?
- What does "finished" mean? Is there anything between new and finished?
- What goes wrong most often right now?
- If this only did one thing well, what would that thing be?
That last question is the most valuable one in the list, and it is the one that protects you. The answer is your Critical priority, and everything else is ranked below it.
Then write it down
# Request Manager - Scope
## The problem, in the client's words
"Messages get lost in WhatsApp. Two of us reply to the same person. I cannot
tell you how many jobs are open right now."
## The one thing it must do well
Show every open request in one place, and who is handling it.
## In scope
- Log a request: customer name, phone, what they want, date received
- Statuses: new, in progress, done
- Assign a request to a staff member
- Filter by status and by assignee; search by customer
- A count of what is open, always correct
- Persists; works on a phone, because that is what they use
## Out of scope, agreed with the client
- Reading from WhatsApp directly. No API access, and not achievable this week.
- Accounts and passwords. No backend.
- Invoicing.
## Assumptions we are making
- Fewer than 200 open requests at a time, so filtering locally is fine
- Two to four staff, entered by hand rather than managedThe out-of-scope list is what protects the team
When the client says on Thursday "can it also send them a text", the answer is not yes and it is not no. It is: that is outside what we agreed, here is what it would cost, shall we swap it for something? That sentence is one of the most professionally useful things in this entire course.
2. The process
| Stage | Output |
|---|---|
| 1. Interview the client | Notes, and the one-thing-it-must-do answer |
| 2. Scope | SCOPE.md, including out-of-scope and assumptions |
| 3. User stories | "As a shop owner, I can see every open request in one place" |
| 4. Break it down | GitHub Issues, each half a day or less, all assigned |
| 5. Build | One issue, one branch, one pull request, one reviewer |
| 6. Review | Somebody else pulls it, runs it, comments, then approves |
| 7. Test | QA lead works through every story on a phone before merge |
| 8. Deploy | A live https URL, from day two, not day five |
| 9. Present | To the client, in their language, not yours |
Deploy on day two, not on the last day
Teams that leave deployment until the end lose their final afternoon to path bugs and a broken build. Deploy something almost empty on day two, then every merge updates a URL that already works. This is the single most reliable predictor of which teams finish.
3. What it must include
- Everything from Project 2: real data, search, filter, four states, modules, phone width.
- State handled properly and persisted: Day 11.
- Validation with messages that say what to do: Day 13.
- Keyboard operable, Lighthouse accessibility above 95: Day 13.
- No XSS, no committed secrets: Day 17.
- Deployed over https with a README a stranger can follow: Day 18.
- A
SCOPE.mdand a closed set of issues showing how the work was split.
4. The presentation
Ten minutes, to the client. Not to your instructor, and not a tour of your code.
| Minutes | What |
|---|---|
| 1 | The problem, in the client's own words |
| 1 | What we decided to build, and what we deliberately did not |
| 4 | Live demo, driven by the person who did not build that part |
| 2 | What broke and what we did about it |
| 1 | What we would build next, and why that order |
| 1 | Questions |
The demo is driven by somebody who did not build that part
It is announced on the day, so you cannot rehearse around it. This is deliberate: a team where only the author can operate a feature has not actually shared the work, and thirty seconds of demo makes that obvious in a way a commit graph does not.
5. The rubric
| Criterion | Marks | What is judged |
|---|---|---|
| Understanding the client | 15 | Did you interview them, is the scope sane, is the out-of-scope list real |
| The product | 25 | Does it solve the stated problem on a phone, with all four states and correct derived values |
| Engineering | 20 | Modules, naming, no dead code, no XSS, no secrets, accessibility above 95 |
| Process | 25 | Issues, branches, pull requests, genuine reviews, deployed early, every member committing across several days |
| Presentation | 15 | Clear, honest, in the client's language, and anybody can demo any part |
What loses marks that teams do not expect
- One person with 80% of the commits. That is a process failure however good the product is.
- Pull requests approved within a minute of opening, with no comments. Nobody read those.
- A demo that only works if you click in one exact order, which means it was never tested by anyone else.
- An impressive feature nobody asked for, while something on the Critical list is missing.
- Presenting in developer language. The client does not know what a state object is and does not need to.
6. Finish properly
- Every team member: fork or clone the final repository to your own account so it is on your profile.
- Add it to your pinned four if it is better than what is there.
- Write your own CV line for it, naming the part you owned.
- Write down, privately, one thing you would do differently in a team next time. Keep it. Read it before your first job.
You are done
Twenty days ago you could build a page that looked right and did nothing. You can now take a problem described by somebody who does not know how software is built, scope it, split it, build it in a team, review somebody else's work, find your own bugs, make it usable by people who do not use a mouse, keep it reasonably secure, ship it to a URL, and stand up and explain every decision in it.
That is not "I know JavaScript". That is a junior frontend developer, and the difference is the whole point of the last four weeks.
What comes next
Level 3 is React, TypeScript and production frontend architecture. Everything React does for you, you have now done by hand: rendering from state, one source of truth, deriving values rather than storing them, components as modules. That is exactly why we did it in this order. React will feel like a shortcut rather than magic, and that is the difference between using a framework and being trapped by one.
Questions teams ask on this project
The client changed their mind on day three. What do we do?
Exactly what a real team does. Do not say no and do not silently absorb it. Say what it would cost and what it would displace: we can add that, and it would mean the assignee filter does not get built this week. Which would you rather have? Then write the decision in SCOPE.md with the date. That sentence and that record are most of what project management is.
Two of us disagree about how to build something. Who decides?
Time-box it to ten minutes. If you still disagree, the Product Lead decides and the team commits to it, including whoever lost. Write the decision and the reason in the pull request so it is not re-argued on Thursday. A team that cannot close a disagreement loses more to the argument than to whichever option was worse.
One of our five is not contributing. Do we carry them?
No, and do not stay silent either. Raise it in the team on day two, not in the assessment on day five: at that point nothing can be done and you all carry it. If it does not change after you have raised it directly, tell your instructor while there is still time to help.
The commit history is read per person, so carrying somebody does not protect them and it does cost you. Being the person who raised it early is the professional move, and it is treated as one.
We are behind. Do we cut a feature or work through the night?
Cut, and say you cut it. A finished small thing with an honest "we did not get to assignment filtering, here is why and here is what we would do next" marks well. A half-built big thing that breaks in the demo does not, and nobody in industry is impressed by an all-nighter that produced a broken build.
Tick before you move on
- ☐ We interviewed the client before writing any code
- ☐ SCOPE.md exists, with a real out-of-scope list and our assumptions
- ☐ Deployed on day two and every merge since has updated it
- ☐ Every member has commits across several days, and reviewed somebody else
- ☐ Any one of us can demo any part of it
- ☐ Accessibility above 95, no XSS, no committed secrets
Quick recap
A brief is a problem, not a specification; the gaps are the work · Ask what the one thing is, and rank everything else beneath it · Write the out-of-scope list down, because it is what protects you on Thursday · Deploy on day two · Present in the client's language, and let anybody demo any part
Level 3: React, TypeScript and production frontend. You have earned it.