Requests
Trace the request from intent to response. Decide where it is authenticated, shaped, logged and allowed to fail.
UK web engineering notes / volume 01
Build the system behind the screen.
A practical fieldbook for people making full-stack decisions: what belongs in a release, where complexity accumulates, and how to leave the next change easier than the last.
One calm loop,
repeated deliberately.
repeated deliberately.
Name the decision and the constraint before reaching for a tool.
Follow the data, ownership and error paths across the whole stack.
Use small checks that make a change legible to the next reader.
Leave a concise note that explains the trade-off, not just the result.
Architecture lenses
Start with the edges, not the framework.
Good full-stack work is rarely a contest of component libraries. It is the quieter work of defining boundaries: what a browser may assume, what a server must validate, and what a team can change safely next week.
State
Keep durable facts separate from a helpful interface memory. They have different owners and different recovery stories.
Change
Prefer seams where a small edit has a local effect. Coupling becomes expensive when every adjustment changes the same release.
Care
Make the ordinary route observable before designing an elaborate fallback. Clear evidence is more useful than optimistic dashboards.
Build decision panel
Three useful points of view.
Switch lenses to surface questions a build can otherwise hide. The choices are prompts, not a prescribed architecture.
The browser is a participant, not a passive screen. Give it clear feedback, a resilient route through partial failure, and only the state it needs for the current task.
- What can be rendered early?
- What should stay available offline?
- Which action needs visible confirmation?
- What does an interrupted request look like?
The service earns trust by being explicit about input, ownership and recovery. Put validation close to the boundary and keep operations boring to repeat.
- Which inputs are accepted?
- Where does authorisation happen?
- What is safe to retry?
- Which error is useful to preserve?
A release is a hypothesis with a route back. Make the intended change narrow enough to observe and the return path understandable before the window opens.
- What changes for a real reader?
- What evidence will be checked?
- Who can pause the rollout?
- What belongs in the release note?
Notebook sequence / 02—05
Make the work visible while it is still small.
A working notebook is not ceremony. It is a place to pin the question, inspect the moving parts, and capture a decision before it turns into folklore.
Local decision checklist
Before you call it ready.
0 of 4 release questions marked
Diagramless story panel
A system is a chain of promises.
Instead of reaching for a neat diagram too early, describe the promises in plain language. This exposes the gaps: promises with no owner, retries with no stopping point, and interfaces nobody can explain.
A reader promises intent
An action begins as a human goal. The interface should tell them what will happen and what is still uncertain.
A boundary promises scrutiny
Server-side code must treat incoming data as untrusted, even when the request started in a friendly part of the product.
A record promises continuity
Stored state should give future requests enough context to continue safely, without inventing invisible dependencies.
A release promises care
Deployment should make it possible to see what changed, assess the result and respond without drama.
Observed work
Notes from the room, not the dashboard.
Good engineering leaves physical traces too: a question beside a keyboard, a deliberate pause in front of a screen, a board that makes work-in-progress visible to everyone nearby.
Reading the build
Three places to look when a change feels bigger than it should.
These are not metrics or claims. They are prompts for a short conversation when a task has started to pull on more of the system than expected.
At the boundary
What assumption crosses from the browser into a service, and where is that assumption checked?
In the handover
Could a teammate discover why the change exists without reconstructing the entire conversation?
At the next edit
Does today’s shortcut make a future adjustment more surprising than it needs to be?
Practical FAQ
Useful answers, held lightly.
The fieldbook favours questions that can be tested in the work itself. Context matters more than a universal recipe.
Validate where the trust boundary requires it. Browser feedback can improve the experience, but the service must still protect its own rules and data.
Enough to identify the intent, the important constraint and any follow-up check. It should give the next reader a starting point, not reproduce every commit.
When it clarifies a decision that words alone leave ambiguous. A diagram is a communication aid, not a substitute for naming the promise or its owner.
Look across the route: reader feedback, browser state, service validation, data ownership and the release path. The review is strongest when it follows the behaviour, not just the files.
open a noteFieldbook dispatch
Send a question into your own local draft.
Use this small form to prepare a message to the fieldbook address. It is deliberately local: the site does not send anything automatically.
Submitting only prepares a browser-local email draft addressed to [email protected]. No message is automatically sent.
Close the notebook
Leave tomorrow a clearer starting point.
A full-stack system becomes more durable when its decisions remain legible: in the interface, in the code and in the short note left for the next person.