The method
Methods starts before development and continues after production. At every stage it asks one question: given what we are trying to achieve, what we know and do not know, this organisation, this product, this architecture and this risk, what is the right method to use now? Then it runs that method.
Sixteen stages, from intent to learning
Requirements are not the starting point. The chain begins with what you are trying to achieve and ends with what the result taught.
Intent
What is actually being asked for, beneath the words of the request.
Outcome
The user or business result that would mean this worked.
Discovery
Whether the problem is understood well enough to act, and what to find out if not.
Opportunity
Which openings are worth pursuing toward the outcome, and which are not.
Journey and capability
Which user journeys and product capabilities change.
Solution
The chosen approach, among the options considered.
Epic
Whether the work needs an epic, or is a single feature.
Feature
Each feature as a contract: observable criteria, what it may touch, what it depends on.
Elaboration
Edge cases, non-functional needs and a definition of done, until the feature is ready to build.
Architecture
The design checked against the product's principles, and the security and privacy methods that apply.
Build
Agents implement one feature at a time, each in its own isolated workspace.
Test
Scripts decide pass or fail, against the exact revision.
Verify
A different agent tries to prove the feature wrong. Evidence is attached to every claim.
Release
Nothing merges unverified. Rollout follows the method the risk calls for.
Observe
Production signals show whether the software works and whether the outcome moved.
Learn
What worked and what failed changes the methods themselves.
The engineering practices
From architecture to release, twenty-eight practices sit behind the stages. They fall into six groups.
Before building
Define before coding
Every piece of work starts as a clear epic, feature or story, or a scoped change, with acceptance criteria, expected behaviour, edge cases, non-functional requirements and an explicit definition of done. Done is never inferred from the prompt alone.
Architecture review before implementation
Check the proposed solution against the project's principles: reuse before duplication, separation of concerns, loose coupling, established service boundaries, deterministic implementation where possible, no needless invention, backwards compatibility, and no major architectural decision without deliberate review. This is a gate, not architecture design.
Plan before building substantial changes
The sequence is PLAN and ARCHITECT, IMPLEMENT, VERIFY, BREAK, FIX, RE-VERIFY. The plan names affected areas, dependencies, risks, likely files, patterns to reuse and the expected verification.
Check standards before implementing
Coding conventions, case-sensitive naming, framework conventions, supported libraries, dependency boundaries, security rules, accessibility standards, browser and responsive requirements and design-system requirements are checked up front, not discovered in QA.
Design system compliance as a hard gate
New interface uses the approved components, patterns, typography, spacing, controls, icons, navigation and interaction rules. No raw controls or one-off implementations where an approved component exists.
Accessibility built in
WCAG 2.2 AA is the baseline, higher where appropriate. Keyboard operation, focus, labels, semantics, contrast, zoom, responsive layout, screen readers, reduced motion and error handling are tested as part of the feature.
While building
Controlled, coherent slices
Do not change large unrelated areas just because it is possible. Break work into coherent slices, and complete and verify each before touching more of the system.
No placeholders posing as finished work
Production ready is the standing standard. No stubs, TODO-based success, hard-coded fake responses or tests that only make the pipeline green. If something is incomplete, the stage is not complete.
Fast local validation
Before committing, run lightweight checks for the changed files: formatting, type checking, linting, targeted checks and relevant unit tests. Do not run the whole CI suite on every commit.
Full validation at the right gate
Heavier validation moves to pre-push, CI or manual validation: full builds, static analysis, complete test suites, integration tests, dependency and security audits, boundary tests and full interface verification. Fast feedback locally, exhaustive proof before integration.
Verifying
Real-system verification
A green test suite is not enough. Start or restart the application and services and exercise the changed behaviour: API results, persistence, service interactions, interface state and downstream effects.
Visual verification of every touched workflow
Take real screenshots and exercise interactions against the running application, at normal desktop width and about 390 px mobile width. Do not assume responsiveness because the CSS compiled.
Automated end to end tests
Exercise the feature as a user would: navigate, click, enter information, save, reload and resume, check persistence, call APIs, and inspect console and network errors and the final state. Screenshots support the evidence but are not proof.
Executable quality gates
A gate verifies actual evidence. If a stage should produce an artifact, record, response or interface state and produced nothing, it cannot pass because no exception occurred. No output is not success.
Trying to break it
BREAK as a separate phase
After normal verification says it works, a different agent or tester that did not build the feature tries to disprove that. The aim is to falsify, not confirm: abnormal sequences, bad input, alternate paths, permission boundaries, state transitions, responsiveness, accessibility, concurrency and failures.
Build and BREAK stay separate
The agent that implements a feature does not also grade it. The BREAK context starts without the builder's assumptions.
Question every important claim
Claims such as responsive, secure, accessible, persisted, tenant isolated, backwards compatible or handles errors become questions. How do you know? What evidence proves it? What if X changes? What if I bypass the interface? What if this dependency fails?
Fix root causes
A problem found by BREAK or QA is not patched for the one failing input. Find the defect class, fix it so adjacent variants are fixed too, and add regression coverage.
Regressions and knock-on effects
A fix is not accepted because the failing case passes. Rerun the related flows, shared components, APIs and consumers so a fix to one feature does not damage another.
Running the project
Security in the lifecycle
Dependency audits, secret checks, authorization tests, tenant-isolation tests where relevant, unsafe-input handling and dependency freshness checks run in CI, not just before production.
Automate conventions
If a rule can be enforced automatically, do not leave it to memory in review. Encode it in linters, architecture tests, template checks, forbidden-pattern checks, naming checks, design-system checks, boundary checks and CI assertions.
Review intent and architecture
Automation removes mechanical issues first. Review then asks whether the change solves the requirement, follows the architecture, adds hidden coupling, duplicates a capability, handles failure and stays maintainable.
Trunk-based, incremental changes
Stay close to main with small coherent commits, stage the intended paths explicitly, and avoid large long-lived changes that are hard to review or recover.
A controlled verification lane
Where resources are contended, heavy builds and tests run in a controlled lane instead of every agent starting expensive jobs at once.
Documentation and state move with the change
Architecture decisions, capability status, known limitations, implementation state and developer instructions are updated as part of the change, with completion evidence recorded.
Finishing and learning
Evidence-based definition of done
Code complete, local checks pass, build succeeds, services run, automated tests pass, the real workflow is verified, desktop and mobile are inspected, accessibility checks pass, an independent BREAK pass is complete, findings are fixed, regressions are rerun, documentation is updated and evidence is recorded.
Release from a known-good state
A release candidate has passed the same reproducible gates. A developer deciding that the branch seems fine is not a gate.
Production feedback feeds the method
A defect found later is not only fixed. It becomes a regression case, a new question, an automated check or an updated standard, so the same class of failure gets harder to introduce.
Three ideas run through it
- Standards become executable
- If a rule can be checked by a script, a script checks it.
- Testing tries to falsify claims
- Verification looks for the case that proves the builder wrong.
- Completion requires evidence
- A feature is done when the evidence exists and is attached.
Build with us as a design partner.
Methods is pre-alpha. A small number of teams will run it on real work while it is built, and shape what it becomes.