Applying the principles: web and application development

This is guidance, not a prescribed stack or organisational process. A single codebase and a fleet of services can apply the same ideas differently.

Start with the product assumption

Before adding a workflow, make clear which user problem it addresses and what would count as evidence of improvement. A registration flow might be judged by successful activation, a reporting feature by whether people can answer an important question, and an operations tool by whether ownership and handoff become clearer. An AI-generated feature list is not a product strategy.

Deliberate boundaries

Separate decisions that are likely to change from mechanisms that should remain stable: authentication, persistence, messaging, business policies and presentation. Use contracts to describe behavioural guarantees, including errors, retries, idempotency, versioning and permission boundaries. A contract is more than an OpenAPI method signature.

The aim isn’t to create a microservice per feature. Start with modules where appropriate. Promote a boundary to a remote interface only when operational or organisational reasons justify it.

Keep agent context appropriate

An agent changing the billing user interface should have the current product rule and billing API contract—not the entire payment processor implementation. A database migration agent needs schema and transactional constraints, rollback requirements and consumers. If a change crosses a boundary, expand context and review the impacts deliberately.

Example delivery slices

A feature such as appointment rescheduling might be decomposed into:

1. Product rules and unresolved cases (cutoff times, time zones, ownership).
2. Domain contract and state transition tests.
3. Persistence and concurrency behaviour.
4. API adapter and consumer contract tests.
5. User interaction, accessibility and error states.
6. Release and rollback checks.
7. Real usage feedback and product refinement.

These aren’t mandatory stages or timeboxes. The point is to preserve meaningful acceptance boundaries.

Tool pipeline

Common repeatable tools include schema linting, code generation from approved contracts, fixtures, migration validation, dependency policy checks, local environment provisioning, vulnerability scans and test execution. Let agents invoke tested commands rather than improvising environment setup or refactoring patterns each time.

Assurance and operational evidence

Use unit and contract tests, migration/recovery checks, access-control tests, integration tests and runtime telemetry. Different reviewers can challenge architecture, threat assumptions or untested failure paths. Model consensus does not establish safety, and automated tests don’t establish customer demand.

Product iteration

Fast implementation may make it possible to evaluate two competing workflows against real users. The valuable result can be a smaller product. Stable capabilities make it easier to change the business behaviour without rewriting identity, storage or audit foundations.

Connected example: Relay work-through uses a fictional web application to show these choices end to end.