CRAFT
MEETS
CLOUD

Questions people ask before writing

Sales FAQ — Answered briefly, including the places where we are not the right choice.

• What size of company do you work with?

  The typical shape is an engineering team of 10 to 80 developers, usually inside a company of 50 to 1,000 people. Big enough that platform and architecture decisions cost real money, small enough that a decision can still be made without going through a committee. Those numbers are orientation, not a gate — write to us anyway if you sit just outside them.

  What matters more is this: there has to be an in-house engineering team that runs the platform afterwards. Without one, knowledge transfer turns into permanent outsourcing, and we are the wrong partner for that.

• We need implementation, not advice. Is that how you work?

  Most of the work is implementation: clusters, pipelines, infrastructure as code, backends. What comes before it is not a consulting phase but the minimum needed to avoid building the wrong thing — measured in days, not weeks. Results land in your repositories, not in a document nobody opens again.

  If implementation means permanently working a ticket queue and taking over operations, we are the wrong choice. We build and hand over; your team runs it.

• We already have a platform team — what would you add?

  We do not replace your platform team and we do not take it over. We come in for one bounded question: an architecture decision the team is split on, a cluster upgrade that keeps slipping, a golden path that exists on paper and nobody uses. The work happens with the team — pairing, reviews, decisions written down in your repository — not around it. Without a team to absorb it, the handover at the end would be worthless.

  If your team already knows the answer and simply has no hours, what you need is capacity. We do not sell capacity and we do not place a person into an open role. Contractors or a staffing partner are the honest answer to that.

• We really just need one more engineer. Is that what you do?

  One more engineer solves a volume problem. We come in when the bottleneck is a decision or missing experience — Kubernetes in production, a migration that has failed twice, a pipeline nobody will touch. Those do not clear up with more hands; they clear up when someone who has made the decision before makes it with you. After that your team carries on without us.

  For a permanently staffed role — running the platform, on-call, the ticket queue — hiring or a contractor is cheaper and fits better. We are not a staffing supplier and we do not take over operations.

• What happens if the one person becomes unavailable?

  We will not talk the risk away: there is no bench to step in. So everything is built where you can keep it — code in your repositories, infrastructure as code, decisions written up as architecture decision records in the project rather than as slides on our machine. Work runs in bounded blocks, each with its own result, instead of one programme stretching over many months. If it stops, you are left with something usable rather than a building site.

  We cannot commit to contractual availability — cover arrangements, response times, on-call. If you need that, you need a supplier with a team and a service level agreement behind it.

• We do not know the final scope yet. How does this start?

  A fixed price for an estate nobody has examined is a guess dressed as a calculation, so we do not quote one. The first block is small and produces its own result: current state, prioritized bottlenecks, an implementation plan with effort estimates. Then you decide whether it continues — with us, with your own people, or not at all. The plan is yours either way.

  If purchasing requires a fixed price for the whole transformation before any assessment, this will not work. We do not put a number on something we have not seen.

• We need someone immediately. How quickly can you start?

  A first conversation happens quickly. A project start depends on current load, and you get told when capacity frees up rather than being kept warm. When it is urgent you get a yes or a no fast, so you can keep looking in parallel. We do not promise a response time, because we cannot guarantee one.

  For an incident in progress we are the wrong call: no on-call rota, no guaranteed response times, no cover. If you need someone in the system today, a supplier with a standby team serves you better.

• We cannot give you production access. Does that rule you out?

  Assessment, architecture and infrastructure-as-code work run without production access: repositories, configuration, metrics, cost reports and conversations with the team give a reliable picture. Where something has to be touched in production, we work through your people — shared screen, your hands on the keyboard. NDA and data processing agreement are settled up front, not alongside.

  With neither production access nor access to the people who have it, a root cause cannot be found. That is not enough for an outage in progress — what remains is an assessment of what you can show us.

• We need on-site support. Is that possible?

  We work remote-first. On-site sessions in North Rhine-Westphalia are straightforward; elsewhere in Germany, Austria and Switzerland they run as planned blocks — workshops, architecture sessions, kickoffs, handovers. Those are the sessions where being in the room genuinely changes the outcome. The rest runs remotely, because daily travel burns time the project needs.

  Being on site every weekday, or holding a permanent desk at your office, is not possible — and less so outside North Rhine-Westphalia. If your model requires it, this is not a fit, and no amount of clever scoping changes that.