The decisions underneath the tools.
Use these principles to question an architecture, explain a tradeoff or decide what to document next.
Own what matters.
Start with the assets whose loss would interrupt your work: identity, content, customer context and the ability to recover. You can rent competent operations around them.
Use the simplest tool that solves the problem.
Write the actual requirement before adding software. Include maintenance in the definition of simple. A feature nobody can operate is not simple for your team.
Understand before automating.
Draw the current work, its decisions and its exceptions. Automation should execute a process someone already understands.
AI assists; humans remain responsible.
Use AI where its output can be checked. Keep problem definition, consequential judgments and release approval with accountable people.
Dependencies are liabilities as well as features.
Every useful dependency has an update path, an operating cost and a failure mode. Document the ones that matter instead of pretending you can remove them all.
Document what you build.
Keep requirements, source identity and observed checks with the project. A future editor should not need the original conversation to make a small change.
Build for the next person.
Use clear names, ordinary editing paths and a short handoff. Consider what happens when the maintainer has less context or different skills.
Portability matters.
Test the export and the destination. A file that cannot preserve the useful relationships may be an archive, but it is not yet a practical exit.
Privacy and accessibility are architecture decisions.
They affect fields, permissions, reading order, interfaces and integrations. Decide them while designing the system, then test them with the main journey.
Teach what actually happened—including the mistakes.
Keep the distinction between an idea, a source inspection and a runtime result. A useful failure can teach more than an unsupported success claim.