The practices behind the work.
What we aim to do on every project. We make no certification claims; these are working practices.
Before we build
What the system must do, what it must not do, who uses it, and how we will know it works. Written down and agreed.
Components, data flows, permissions, and failure behavior sketched and reviewed before implementation.
While we build
Code and configuration are kept in version control with a history of changes.
Development, testing, and production are kept apart so experiments do not touch live data.
Keys and passwords live in environment configuration, never in code or documents.
Least-privilege access to client systems, granted for the project and removed afterwards.
Retries, timeouts, fallbacks, and clear alerts for the failures we can anticipate.
Before and after release
Normal cases, edge cases, and failure scenarios, with results recorded against agreed criteria.
A written release process and a way to roll back.
How it works, how to operate it, and what its limits are.
Logs and checks appropriate to the system so problems are noticed.
Agreed support covers fixes and upstream changes; new features are scoped separately.
Have a business problem worth solving?
Explain your requirements and we will discuss a suitable approach.