By Ricky Kirkendall
“This isn’t going to be a whole thing, is it?”
That is, in the plainest terms, the question everyone has on our first call.
And it's fair. By the time most customers talk to us, they've already worked through the logic on their own:
The features check out. What they're really asking about is the gap between their system and ours. How much work is it going to take to bridge it? How many of their own people need to be involved? How long before they have something real running?
Most enterprise infra doesn’t fail in the architecture. It fails in the adoption gap. The gap is where timelines slip, internal champions burn out, and pilots stall.
In enterprise rollouts, the hidden work is always the same: map the idealized system to the one that actually exists, surface the real constraints early, and close the distance between “it should work” and “it’s working for us.”
The job of folks like me is to own that hidden work.
A big part of my job as a solutions engineer at Crafting is making that gap smaller than customers expect. We figure out where a customer is, what their system actually looks like, and what needs to happen to get them running on Crafting in days and weeks, not months and quarters.
We're comfortable working on those timelines because we've done it before, and we know what it takes to get there. Not in some idealized version of their setup, but in the one they actually have.
The goal is simple: return value at every step. The answer to the question of “Is Crafting working for us?” should always be “Yes”. In a small way at first, then in a much more impactful way as we build.
We’ve designed a very intentional flow to optimize for getting customers to be as successful as possible, as quickly as possible. It starts with a customer sending me a document about defining success criteria for our PoC together. From there, we figure out what they need to see working, scope the rollout to get there quickly, and build from that.
This work doesn't end with the PoC. Once a team is live on Crafting, the nature of the work changes, but someone has to still be there. How much involvement is needed depends entirely on the customer.
Some teams want to be self-serve. They want documentation, examples, and the ability to move on their own. That is fine. If they ask a question and the answer is in the docs, I still try to answer it directly in the context of what they are doing, then point them to the reference if they want to go deeper. They are looking for a platform that works and stays out of their way. We respect that.
Other customers come in with questions that sound precise, but the real issue is slightly underneath the question they asked. Someone will ask how to configure a specific daemon behavior, and the phrasing suggests they have a clear picture of what they want. But when I dig in, I find they are approaching the platform in a way that will make things harder for them down the line, or solving the right problem in a way that will create new ones. In those cases the most useful thing I can do is ask: what are you actually trying to accomplish? Once I understand that, I can usually help them find a shorter path than the one they were on.
Then there are the teams deep into it. These are not edge cases. It’s the bulk of how I spend my time, and some of the most important work I do.
Once a team is using Crafting seriously, we start to see issues specific to their system. My role evolves into working as a true implementation partner with their engineers. When we need to, I pull in other members of our core eng team.
This week a customer asked why a daemon was not starting after their sandbox booted. The configuration looked correct. I walked through the entire definition with them, compared it against the daemons that were starting successfully, and traced it to a repo checkout that was taking so long it caused a downstream permission failure. We pared down the build script, surfaced the failure mode, and resolved it in a little over an hour.
The same applies to teams building agent workflows. One team had an end-to-end flow running: request triggers agent, agent spins up a Crafting sandbox, completes a task, opens a GitHub PR. Then they needed custom configs for authorship and handling PRs according to team norms.
That’s the enterprise workflow integration we’ve honed: identity, permissions, audit, and norms.
We worked through it and had a solution within a few days.
Most of the questions I get these days are some version of that pattern. Developer experience teams trying to stand up agentic environments that actually work while meeting enterprise security and compliance requirements. I am seeing all of our customers work through this in parallel, running into similar problems, finding different solutions depending on their scale and constraints. That perspective compounds. Each engagement teaches me something that makes the next one faster.
This function compresses time-to-value by removing ambiguity—technical and organizational.
This is why “customer success” for infrastructure isn’t a support queue. It’s an implementation function: mapping the platform onto a messy, evolving system until the answer to “Is Crafting working for us?” is yes—every week.
Crafting's product is strong. The architecture holds up. The platform can be as self-serve as a team wants it to be. But the difference between infrastructure that gets adopted and infrastructure that sits on the shelf is often whether someone on the vendor side actually owns the outcome. That is a deliberate choice Crafting made. Someone owns every customer's success, and that is the job I do.
The features get a team in the door. Having someone who knows the platform, knows the customer's system, and is accountable for the result is what makes those customers successful.
