Relay / fictional worked example
Working through a product, not just writing code
On this page
An illustrative end-to-end example of how the nine principles connect. Relay, its market assumptions and its feedback are fictional; they are used to explain the mechanics, not presented as actual research or a Westforge client project.
Imagine a small team building a product for coordinating maintenance requests across several sites.
The initial idea sounds straightforward: staff report problems, a coordinator reviews them, assigns someone, and everyone can see the status. The first proposed feature list also includes automated urgency classification, notifications, scheduling, reporting and integrations with existing systems.
An agent could begin implementing the list immediately. That might produce a surprising amount of working software in a short time. It could also produce an expensive, interconnected system before anyone knows which features make the product valuable.
This example starts somewhere else.
Establish what the product is trying to change
The working product hypothesis is that small operations teams struggle less with deciding which requests are urgent than with knowing who owns them. That assumption needs testing. It is not a reason to remove urgency classification immediately, and it is certainly not a fact about the entire market.
The team writes down the target users, the alternatives they already use, and the questions that could falsify its current position. A shared inbox, a helpdesk and a facilities-management suite are different alternatives, with different strengths. The aim isn’t to reproduce all of their features; it is to find out whether a narrower ownership workflow is useful.
At this point, product discovery has already influenced engineering. The first implementation should make request ownership testable, not deliver everything in the concept deck.
Design the stable mechanics
The team separates three kinds of responsibility.
The mechanics establish dependable capabilities: request records, identity, replay semantics and audit events. Integration composes those capabilities into intake and assignment workflows. Product orchestration determines what users see and which decisions the experience asks them to make.
This is not an instruction to create three microservices or three plugins. A well-structured monolith can use the same distinction. What matters is that the product’s current opinion about urgency does not become an invariant of the request store.
The team documents a contract: if an external submission arrives twice with the same source identifier and the same content, the second delivery must return the original record. If the same identifier arrives with contradictory content, the system must raise a conflict instead of overwriting or silently merging the request.
That contract matters because ‘duplicate’ is otherwise ambiguous. Two people can report the same leaking tap without being duplicate deliveries. An agent guessing the difference could discard genuine work.
Turn the design into small outcomes
Rather than ‘build the maintenance platform’, the initial work is divided into independently testable steps. First, define the record and its replay contract. Next, implement storage mechanics. Then connect intake and auditing. Later, add ownership rules and an experience that real users can evaluate.
Each work order names the design inputs, files that may change, acceptance tests and reasons to stop. It does not need a mandatory one-hour timebox, but it must be small enough to understand the result.
Suppose an agent working on replay handling claims the storage provider cannot support the contract. It starts sketching a separate key cache and synthetic identifiers. That is a plausible engineering response to an alleged limitation. It is also the wrong way to proceed if the premise is unverified and the workaround violates the design.
A bounded work order requires it to stop, show the supposed incompatibility and ask for a decision. A quick capability check may reveal that nothing needs reinventing. If the provider genuinely cannot satisfy the contract, the architecture changes deliberately rather than by accident.
This is how control can save tokens and prevent months of future complexity: not by forbidding AI reasoning, but by denying it unilateral authority to create a different system.
Make verification independent
The first executable slice implements only request intake. The included Python example has tests for replay, conflicting duplicates, invalid inputs and audit emission. Those are mechanical checks of agreed behaviours. They are not the agent’s opinion that the work is correct.
The tests also show a limitation: if an audit sink fails after the in-memory store accepts a request, the event may be missing. That is a deliberate illustration of a production issue, not something to hide behind a successful test count. A real adapter would need a transactional strategy and further failure testing.
Independent review asks different questions. One reviewer challenges architecture; another tries adversarial cases; another checks whether the acceptance criteria have evidence. Their findings are reproduced and checked against contracts. Three reviewers agreeing is no substitute for evidence, and model consensus cannot establish whether the product is wanted.
Use implementation to challenge the product
The team can now evaluate a credible ownership workflow. In the fictional example, participants are more concerned with who is dealing with a request than with its predicted urgency. The team chooses not to continue automatic classification in the initial scope. It strengthens ownership visibility instead.
That is product learning, not implementation failure. The objective wasn’t to complete the original feature list. It was to learn what the product should become without building an architecture that resists change.
Because the mechanics and orchestration are separated, removing the idea does not force the team to rewrite request storage or audit semantics. Stable capabilities support changing product decisions.
Of course, invented feedback cannot prove market fit. A real project needs actual user research, competitor evidence and behavioural data. A successful prototype can demonstrate usability without proving commercial demand.
What we actually achieved
In this example, the concrete technical proof is deliberately narrow: the in-memory intake contract and its tests. Assignment, tenant permissions, durable audit, operational reliability and release safeguards are specified as future work, not quietly treated as completed.
The broader result is a development model where product and engineering continuously influence one another. Strategy can change through feedback; design can be challenged by implementation; contracts prevent unintended consequences; tools make recurring operations repeatable; independent verification tests claims; and decisions remain connected to the product.
The number of lines the agent wrote is irrelevant. The meaningful questions are whether the next product assumption can be tested, whether the system still respects its intended boundaries, what evidence supports the result, and what work can now be avoided.
That is the difference between accelerating implementation and accelerating useful product development.