Consulting
First understand what runs. Then decide who operates it.
Containerisation, evaluating Kubernetes, migration, operating models. Consulting that ends with something usable rather than a slide deck.
gh0stservice Engagement · typical course
First call
Free, twenty to thirty minutes, no obligation.
Taking stock
We look at what actually runs, not at what is documented.
Build or assess
Depending on what is needed: a pilot, a basis for a decision, or both.
Handover
Documentation that still holds once we are no longer involved.
Handed over
- Typical length
- 2–8 weeks
- From taking stock to a basis you can decide on.
- Outcome
- Something running
- A pilot, an operating model, or both.
- Afterwards
- Your call
- You operate it, we operate it, or you take the result and go elsewhere with it.
Working together
How an engagement runs
Consulting that creates dependency is bad consulting. That is why handover is part of the work, not an afterthought.
| How an engagement runs | Yours | Ours |
|---|---|---|
| Starting point | You bring the problem and the context. | We bring experience from comparable environments. |
| Taking stock | You give us sight of what actually runs. | We write it down so it stays readable without us. |
| Decisions | You decide. | We put the options side by side, with costs and risks attached. |
| The result | Yours, even if you move on to someone else. | We hand over documentation, charts and operating guides. |
Topics
What we usually work on
Most engagements are a combination of two or three of these.
Write to us about what is not working.
The first conversation costs nothing and often ends with a useful answer already.