How we work
Nothing here is unusual. It is written down because knowing what happens next is most of what makes a technical project bearable.
-
Scope
A conversation, then a written summary of the problem as we understand it, what we would do about it, what it costs and how long it takes. If the honest answer is that you do not need us, that is what the summary says.
-
Build or migrate
Work goes out in small pieces you can see running, not in one reveal at the end. You get an environment to click through from the first week, and a standing weekly point of contact.
-
Run
Monitoring, patching, backups and a tested restore. Someone is on the other end of the alert. We would rather find the failure at 02:00 than have you find it at 09:00.
-
Hand over
Documentation written for whoever comes next, access in your name, and a walkthrough with your team. This step exists whether or not you are going anywhere.
What we hold to
Boring technology, chosen on purpose
We pick tools with long support windows and a large pool of people who know them. Novelty is a cost paid by whoever maintains the system in five years.
Estimates with the uncertainty left in
A range and the reason for the range beats a confident single number that quietly becomes a target.
Written decisions
Why a thing was built this way is recorded next to the thing. Institutional memory should not live in one person's head, including ours.
Security is part of the build
Least privilege, patched dependencies, tested backups and sane defaults from the start, rather than a review bolted on before launch.
Sound like a fit?
Tell us what you are dealing with and we will reply with what we would actually do about it.