Case study 01 — Draft
Attendance App
A draft case study for the attendance app. Add the real audience, stack, and one outcome. Nothing below is a claim yet.
Illustrative mockup — replace with a real screenshot.
The short version
- What it is — add one sentence.
- What you built — add the stack and the main flow.
- What was hard — add one decision or one bug.
Who it was for
Add the real audience. Who used it, how many, and what they did before the app existed. If the answer is “me, for a course”, say that clearly.
The problem
Add the problem in two or three sentences. What was broken, who felt it, and what did they do instead? Where possible, use a real observation, not a market-size guess.
How it works
Add the stack and the request flow: what the client sends, what the server stores, and what the user sees. Replace the illustrative diagram with the real one when it exists.
The hard part
Add one decision or bug you can explain for three minutes. The date boundary, a duplicate submit, an auth redirect, a permission — something with a trade-off and a test.
The outcome
Add one number you can defend: records, users, latency, test count, or time saved. If there is no number yet, describe the mechanism instead of inventing one.
What I would change
Add one honest thing you would do differently: a schema choice, a feature you cut too late, or a test you wish you had written first.
Draft case study. The structure is real; the details are placeholders. Add a repository, a live URL, or a screenshot before showing this page to a recruiter.
The process
Three moments from the build. Add real dates and commits when they exist; until then, this is the shape of the story.
The problem
Add the real problem: who had it, what they did before, and why it mattered. Two or three sentences, no adjectives.
The build
Add the stack and the main flow. Name the one decision you would defend in an interview.
What broke
Add the bug or dead end that cost the most time, and the fix. This is the part people remember.