Technical Philosophy

Technology in Service of People

We use technology to extend human capability, not to replace it. Every technical choice is filtered through the question: Does this give people more control, clarity, or care?

Core Principles

1. Start Simple

• Choose the calmest tool that satisfies the need.
• Avoid premature optimisation and unnecessary abstraction.
• Document why we declined more complex options.

2. Secure by Design

• Threat modelling begins with people, data, and place.
• Zero-trust patterns, access reviews, and incident drills are routine.
• Security notes live alongside code and stay understandable to non-specialists.

3. Measure What Matters

• User experience and environmental impact guide performance work.
• Metrics are transparent, version-controlled, and revisited regularly.
• We stop collecting data when it no longer serves people.

4. Maintainable by Humans

• Code is self-documenting, linted, and covered by meaningful tests.
• Runbooks and handover guides publish with every release.
• We budget time for refactoring and debt, not just new features.

Stack Preferences

Backend

• Languages: TypeScript, Go, Python.
• Frameworks: Next.js, FastAPI, or tools clients can comfortably support.
• Datastores: PostgreSQL by default, plus lightweight caches when needed.
• Hosting: Platforms that support portability and sovereignty requirements.

Frontend

• Framework: React with Next.js for consistency.
• Styling: Tailwind CSS with shared design tokens.
• State: Context or Zustand when necessary — otherwise plain React.
• Testing: Jest and React Testing Library, with accessibility checks baked in.

Operations

• Containerisation: Docker for reproducibility.
• CI/CD: GitHub Actions with human sign-off gates.
• Monitoring: Open-source first (Prometheus, Grafana), with SaaS only when justified.
• Infrastructure as Code: Terraform or Pulumi with readable modules.

Ways of Working

Code Quality

• Peer review on every change, including documentation.
• Static analysis and tests run automatically, with failures treated as teaching moments.
• Architecture decisions logged in ADRs or lightweight memos.

Deployment & Reliability

• Feature flags and gradual rollouts protect users.
• Observability dashboards include plain-language summaries.
• We rehearse failure scenarios and share the learnings openly.

Continuous Improvement

• Quarterly architecture reviews identify simplification opportunities.
• Technology radars highlight what we are adopting, watching, or pausing.
• Post-incident reports focus on systems, not blame.

Interested in the people behind these practices? Head to our Team page or explore the Optional Reading section.