Specifications and a full-stack vertical slice
আগে ঠিক করো কী হলে কাজটা সঠিক। তারপর mobile, API আর review screen একই নিয়ম মানবে।
Guess first
Pick an answer. You will see if you were right at the end of the lesson.
What if the first request succeeded but its response was lost?
Real-world analogy
What is it?
A specification captures behaviour before implementation. A vertical slice connects a small user action through UI, storage and backend. It reveals contract mistakes earlier than building all screens first. Specifications do not need to predict every edge case; update them when new evidence appears.
Real-world relevance
One shared support-ticket product, three optional entry points. Frontend: Specify loading, empty, error and success states, keyboard access and double-submit behaviour. Backend: Specify schema validation, authorisation, idempotency and error response contracts. Mobile: Specify offline persistence, reconnect retries, app restart and stale response handling.
Key points
- Start with one journey — Capture an offline ticket, reconnect, sync it once and display pending review.
- Specify states — Use queued, syncing, saved and failed states with permitted transitions.
- Define duplicates — An idempotency key identifies one operation; retries must not create new tickets.
- Define authorisation — A logged-in user can only read and modify tickets they own.
- Define network failure — Keep local input after timeout and allow a bounded retry.
- Write acceptance examples — Include empty input, duplicate request, offline restart, expired session and wrong owner.
- Version contracts — Write the request and response before splitting implementation work.
- Frontend practice — Specify loading, empty, error and success states, keyboard access and double-submit behaviour.
- Backend practice — Specify schema validation, authorisation, idempotency and error response contracts.
- Mobile practice — Specify offline persistence, reconnect retries, app restart and stale response handling.
Quick check
Answer from memory — scrolling up first makes it stick less.
What artifact demonstrates this lesson?
Which statement is defensible?
Code example
Feature: idempotent ticket sync
Given request key K was saved successfully
When the client retries K after losing the response
Then the backend returns the same ticket id
And it does not create a second ticket
And a different user cannot retrieve that ticketLine-by-line walkthrough
- 1. This is a behaviour specification, not executable Gherkin without a test runner. Implement a unique key and ownership check in the backend, then an integration test.
Spot the bug
On timeout: generate a new request key and retryNeed a hint?
Show answer
Explain like I'm 5
Fun fact
Hands-on challenge
More resources
- Building effective agents (Anthropic)
- Download the free offline lab (Python, tests and instructions) (Teamz Lab)
Lock it in