The tooling that sits on the platform rather than on a product roadmap: CLIs, controllers, actions and the automation nobody has time to write.
Every platform has a last mile somebody does by hand. A runbook with eleven steps, a spreadsheet that decides who gets access, a deploy that needs one person awake. It works, right up until that person is on leave.
This is the work of turning those steps into something the team runs without thinking about it. It is not a product and it will never have a roadmap, which is exactly why it never gets built, and why it is worth paying somebody to build properly and hand over.
ICF is early, so there are no named client logos here yet. What there is: public code you can open and read, and work described without naming whose it was.
01
Watch the manual version
The steps as they actually happen, including the ones nobody writes down because everybody knows them.
02
Automate the worst one first
The step that causes the most incidents or eats the most attention, not the one that is easiest to build.
03
Put it in their hands
Used by the team while I am still here, so the gap between what I built and what they needed shows up early.
04
Hand over
Tests, docs written for whoever inherits it, and a period where I am still reachable.
A core process runs on a spreadsheet and one person who knows the steps
Product teams open a ticket to infra to start anything
The same GitHub Actions workflow is copy-pasted into thirty repositories
An internal tool everybody depends on has no owner
Tell me what you are running and what is slowing you down. I reply within one business day, and I will say so if this is not work I should take.
Taking a small number of contracts