Status: Recommended guidance. Apply proportionately to the engagement, product risk, signed agreement, and delivery context. This document is not a warranty or fixed process. See DISCLAIMER.md.
Begin with the user, business, and operational outcome. Features, frameworks, and architecture are means—not the objective. A team should be able to explain what will become measurably better and what evidence would change the plan.
Record decisions that are expensive to reverse, materially affect risk, or constrain other teams. Capture context, options, tradeoffs, owners, and review triggers. Documentation should support a decision, not simulate certainty.
Prefer small, integrated increments that stakeholders can inspect in working software. Increment size should reflect coupling, release risk, and the cost of feedback. Some migrations or safety-critical changes may require a larger coordinated release.
Testing, security, accessibility, observability, privacy, and operations should enter planning when relevant—not only at the end. The depth of each activity should be proportionate to impact and threat.
Favor explicit contracts, understandable boundaries, reversible decisions, and maintainable defaults. Avoid speculative abstraction. Invest where change is likely or failure is costly.
Automate checks that are frequent, objective, and valuable: formatting, types, tests, dependency checks, builds, migrations, and deployment health. Keep human review for judgment, ambiguity, risk, and product intent.
Production behavior is part of engineering. Define ownership, telemetry, recovery, support paths, and safe change mechanisms before a consequential release.
Distinguish facts, assumptions, estimates, constraints, and unknowns. Raise material risks early. Do not convert an estimate into a guarantee or hide uncertainty behind process language.
Collect and expose only what is needed. Protect confidential and personal information. Design for real users, including people with disabilities, different devices, languages, and network conditions where applicable.
Treat defects and incidents as opportunities to improve controls, architecture, documentation, and feedback loops. Focus on contributing conditions rather than blame.
- What is the impact of failure or misuse?
- Which obligations come from the signed agreement or applicable law?
- What evidence is required before release?
- Which decisions are reversible?
- What must remain understandable to the next team?
These principles are defaults for reasoning, not contractual promises or a checklist that proves quality by itself.