Boring by default
Standard tools and stock configurations. A system that a competent stranger can understand on a bad day is worth more than a clever one.
Approach
Nothing unusual here. The value is mostly in doing ordinary things consistently and writing them down.
How a piece of work usually runs
- 1. Look first
- A short review of what exists today — hosts, services, access, backups, and whatever is currently held only in someone's head.
- 2. Write it down
- A plain summary of what we found and what is worth changing, ordered by risk rather than by how interesting it is.
- 3. Agree the scope
- Fixed work for a defined change, or a small recurring block of hours for maintenance. No open-ended retainers that nobody reviews.
- 4. Change carefully
- Small steps, a way back from each one, and changes made outside busy hours where that matters.
- 5. Hand it over
- Runbooks and configuration left in your repository, in your accounts, under your control. Nothing depends on us staying involved.
Principles
Documented as we go
If a change is not written down it did not really happen. Notes live with the code, not in a chat thread.
Least access
We ask for the narrowest access that lets the work happen, and expect it to be revoked when the work is finished.
No lock-in
Accounts, domains and repositories stay in your name. Leaving should be a boring administrative task, not a negotiation.
Working arrangements
We work remotely and asynchronously most of the time, with scheduled calls when a decision needs one. Billing is hourly or per agreed piece of work, invoiced monthly. Anything urgent and out of hours is agreed in advance rather than assumed.
If you would like a written scope or an estimate before committing to anything, just ask — that part is free.