How software products work, in plain English
Behind every screen sit a few simple parts. Learn them, model what your product remembers, and make your first decision.
Tonight’s outcomes
- Explain the five parts of a web product in plain English, using your own product
- Model your product’s nouns: entities, fields, relationships, owner and lifecycle
- Choose a simple first architecture and explain why it beats a fashionable one
- Write an Architecture Decision Record that a newcomer could follow
- Explain authentication vs authorisation and apply five security-by-design basics
OUTPUT · System sketch + data model in 03-design.md + first ADR in product/decisions/
Anatomy of a web product
- INTERFACEWhat people see and touch: pages, forms, buttons, emails. The dining room.
- LOGICThe rules: who may book which slot, what confirming does. The kitchen.
- DATAWhat the product remembers: tutors, slots, bookings. The pantry and ledger.
- INTEGRATIONSServices it relies on: email, calendar, payments. The suppliers.
- OPERATIONSHosting, backups, monitoring, support. Opening, cleaning, safety checks.
Every product, from TutorDesk to a bank, has these five parts. Only the size changes.
What happens when a learner books a lesson
“You press Book and the app just saves it somewhere.”
Browser sends the request → server checks who you are and that the slot is free → database saves a requested Booking → email service tells the tutor → tutor confirms → learner is told.
Ask
- Which of the five parts does each step use?
- What if two parents request the same slot at once?
- What should happen if the email service is down?
- Which step must never trust what the browser says?
Model the nouns
- ENTITIESThe things the product remembers: Tutor, Learner, Slot, Booking
- FIELDSWhat you store about each: a Slot has a start time, a length and a status
- RELATIONSHIPSHow they connect: a Tutor has many Slots; a Booking joins a Learner to a Slot
- OWNERSHIPWhose record it is, and who may see or change it
- LIFECYCLEThe states it moves through: requested, confirmed, declined or cancelled
Find the nouns in your journey. If you cannot name it, you cannot store, secure or measure it.
TutorDesk’s data model
“One big spreadsheet with a column for everything about every lesson.”
A Tutor has many Slots and many Learners. A Booking joins one Learner to one Slot, with a status: requested, confirmed, declined or cancelled. Every record belongs to one Tutor.
Ask
- Where does a parent booking for two children fit?
- Who may see a learner’s phone number?
- What happens to a Booking when a Slot is cancelled?
- Which fields can wait until version two?
Fashionable vs boring architecture: why boring wins early
Fashionable
- Many small services talking to each other over a network
- Several databases, queues and tools to learn and pay for
- Built for a scale and a team you do not have yet
- More places to break, more to secure, harder to change
Boring: a modular monolith
- One application and one database, deployed as one unit
- Clear modules inside: accounts, bookings, notifications
- Well-known frameworks with years of answers online
- Easy to change while you are still learning what to build
Choose the simplest design that serves the next year. Split it only when evidence says you must.
Architecture Decision Record
- CONTEXTThe situation and forces: solo founder, first 20 tutors, first slice in weeks
- OPTIONSAt least two real choices, each with honest trade-offs
- DECISIONWhat we chose, in one sentence, and the main reason
- CONSEQUENCESWhat gets easier, what gets harder, and what we accept
- REVISIT WHENThe signal that reopens it, e.g. a second team or ten times the load
An ADR takes twenty minutes and saves weeks of re-arguing. Future you, and Claude, will read it.
Authentication vs authorisation
Authentication: who are you?
- Proves identity: a password, an email link, a sign-in provider
- TutorDesk: “This person is Priya, a tutor.”
- Use a proven library or service; never build your own
Authorisation: what may you do?
- Checks permission on every request, on the server
- TutorDesk: “Priya may confirm her own slots, not another tutor’s.”
- Signed in but seeing someone else’s data is a common, serious flaw
Signing in proves who you are. It never proves what you are allowed to see.
Security by design: five basics
- LEAST DATACollect only what the first slice needs: no dates of birth, no home addresses
- SECRETSPasswords and keys live in environment settings, never in code or chats
- VALIDATE ON SERVERCheck every input on the server; the browser can be bypassed
- PERMISSIONSEvery record has an owner; check it on every read and every change
- BACKUPSAutomatic backups with a tested restore, so yesterday’s bookings survive
Security is cheapest at design time. Write these into your ADR’s consequences tonight.
Claude as architect: questions first
I’m designing TutorDesk, a booking tool for solo tutors with 5–30 learners. I’m not technical. I need a first architecture I can build with Claude Code, and I want help deciding, not just an answer, so that I can explain the choice to others. <design>[PASTE JOURNEY, DATA MODEL AND CONSTRAINTS]</design> First ask me up to five questions whose answers would change your advice. Then compare two options in a short table: cost, complexity, time to first slice, risks. Recommend one; if you’re unsure, say so and what would settle it. Finish with an ADR (context, options, decision, consequences, revisit when) and a Mermaid diagram of the parts. Done = I can explain the choice in two minutes.
Check the response
- Did it ask questions before recommending anything?
- Are both options real, each with honest downsides?
- Could you explain the ADR to a friend in plain words?
Workshop: system sketch, data model and ADR
Draw how your product works, model what it remembers, and record your first architecture decision ready for week 4.
- 0–10 min: sketch the five parts for your product; name only the integrations you truly need
- 10–25 min: list your nouns; write fields, relationships, owner and lifecycle for each
- 25–40 min: run the architect briefing in your Claude Project; answer its questions honestly
- 40–50 min: write ADR 0001 in your own words; add the five security basics to its consequences
- 50–55 min: explain your sketch to a partner in two minutes; fix what they could not follow
Sketch and data model in 03-design.md; ADR in product/decisions/
Design rubric
- System sketch shows all five parts and gives a reason for every integration
- Data model lists entities, key fields, relationships, owner and lifecycle states
- Every stored personal field is needed by the first slice, with the reason written
- ADR compares two real options and states consequences and a revisit trigger
- Each entity has a written rule for who may read it and who may change it
- A partner can explain the sketch back in plain English after two minutes
NEXT · Week 4 turns this design into a story map and backlog. Bring 03-design.md and ADR 0001.
© 2026 MVP Studios Ltd. MVPAI™ and the MVP Founders Programme materials are original works of MVP Studios Ltd. All rights reserved. No copying, redistribution or commercial use without written permission. Course terms