Tasks, with accounts | backend

The spreadsheet

Carter & Sons is a four-person design studio in Leeds. They track client work in a shared spreadsheet, and last week two people edited the same row and a deadline disappeared. Nora, who runs the studio, wants a small web app instead: each person signs in and keeps their own list of tasks, each with a title, an optional due date and a done box.

What it has to put up with

It has to work on the old laptop in the corner and on a phone in the car park. A task written on Monday is still there on Friday, whatever happened to the server in between. Nobody should ever see or touch somebody else's list, whether they guess an address or edit a form.

And it has to run somewhere the studio can reach, at an address Nora can type into her phone.

Not the job

No sharing, no teams, no notifications, no password recovery: if someone forgets theirs, Nora makes them a new account. Nobody is judging the colours.

Language, framework, database, how the app knows who is signed in and where it runs are yours to choose. Write the choices down in DESIGN before you build.

The work, in 3 milestones

Each milestone says what must be true and the drill that proves it. You close a milestone when its drills pass.

M1 · A task list that survives a restart

One list, no accounts yet: tasks you can add, change, complete and delete, still there after a restart.

R1
A person can add a task with a title and an optional due date, change both, mark it done or not done, and delete it.
R2
Tasks are still there after the app is stopped and started again.

D1 R1 , not recorded yet
Add a task with a due date, change its title and its date, then clear the date, mark it done and then not done, and delete it. Reload the list after each step.

expectAfter every reload the list shows exactly the change you made, and after the delete the task is gone.
D2 R2 , not recorded yet
Add three tasks, stop the app completely and start it again, then open the list.

expectThe three tasks are there, with their titles, due dates and done state unchanged.

M2 · Everyone signs in and sees only their own list

Accounts with passwords, a session that outlives a restart, and no way into somebody else's tasks.

R3
A person can create an account with an email and a password, sign in and sign out. Someone holding a copy of the database cannot sign in as anyone with what it stores.
R4
Nobody can see, change, complete or delete another person's task, whatever address or form data they send.
R5
Someone who is signed in is still signed in after the app is redeployed. Signing out ends it: whatever the browser held no longer works.

D3 R4 , not recorded yet
Sign in as Ana and add a task. Copy its address or id from her browser. Sign in as Sam in another browser profile and try to open that task, change its title, mark it done and delete it, sending the requests yourself if the pages offer no way.

expectEvery attempt is refused, Sam never sees the task's title, and Ana's task is unchanged in her list afterwards.
D4 R3 , not recorded yet
Open the database and read what it stores for one account: its row and anything kept for its sessions. Then sign out, and request the task list with the cookie or token the browser held before signing out.

expectNothing stored is the password or a value that signs you in when sent as it is, and the old cookie or token is refused (a 401, or the sign-in page).
D5 R5 , not recorded yet
Sign in, then restart the app and reload the list in the same browser.

expectThe list loads without asking you to sign in again.

M3 · Running where the studio can open it

A public HTTPS address that works on a phone and keeps everyone signed in through a deploy.

R6
The app runs at a public HTTPS address, and everything it does works in a phone's browser.

D6 R6 , not recorded yet
On a phone on mobile data, open your public address, create an account, add a task with a due date and mark it done.

expectEvery step works in the phone's browser over HTTPS, without zooming to reach a button.
D7 R5 , not recorded yet
Stay signed in on the phone. Change something visible, deploy it the way you normally deploy, then reload the list on the phone.

expectThe change is live, you are still signed in, and the task from D6 is still there.

Questions for the stakeholder

They reveal no requirement, but the answers shape the design.

start the project to ask

Technical guidance

▸Get one page that lists and adds tasks running first, and make it survive a restart before you add accounts.

▸Deploy as soon as M1 works. A first deploy is easier with one page than with ten.

▸From the moment accounts exist, keep two browser profiles open, one per person.

Done when

Every drill above passes, and:

The README says how to run it locally and how it is deployed.

No password, key or connection string is in the repository.

# Tasks, with accounts