Note - this is a strangely (but understandably) controversial topic both internally and externally. Lots of people are against the idea of heavy pilots, but we believe it's important to stick to our principles and do right by our customers to build healthy, long-term relationships for Crafting.

‍

Most B2B companies treat pilots like a fast path to “yes” with a lightweight trial, a polished demo, and just enough good vibes to get a signature.

We run pilots differently on purpose. It’s slower. It’s heavier. And it’s worth it.

Because in infrastructure, especially in an AI era where it’s easier than ever to fake outcomes, the pilot is the first real proof of trust.

The classic pilot playbook (and why it’s broken)

A lot of pilots are engineered for optics:

• They’re demos wearing a pilot badge. The environment, workflows, and constraints don’t resemble production.
• They overfit to a single feature request instead of the underlying operational problem.
• They demand faith-based leaps on security, reliability, and governance.
• They hide the hard parts behind “we’ll solve that after procurement.”

If you’re selling a lightweight SaaS tool, you can sometimes get away with that.

Powering an organization’s end-to-end SDLC with agents, engineers, CI/CD, permissions, environments, and auditability demands more.

Committing to a platform isn’t buying a feature

When a partner works with Crafting, they’re not delegating a UI toggle. They’re delegating capabilities around what an organization can reliably ship. They’re depending on us for secure access for developers, agents, and anyone who interacts with hem. They’re counting on us for operational reliability to scale real systems under real constraints.

Partners might show up asking for “agents.” What they end up really needing is standardization, enterprise guardrails, repeatable workflows for humans and agents, and a consistent experience across organizations.

That’s why we use the word partner. A partnership is built on repeated proof, shared success criteria, and transparent tradeoffs. Not persuasion.

What our pilots are designed to do

Our pilots aren’t about producing a quick “wow.” They’re designed to:

• Reduce perceived risk by surfacing reality early
• Build trust through transparency (security, permissions, access, constraints)
• Produce evidence, not anecdotes
• Make the long-term engagement feel seamless because nothing fundamental changes after the pilot

If we want engagements that last 5 to 10 years, our pilots need to reflect what that ongoing engagement actually looks like.

How we run pilots

1. Structure: explicit, shared, living source of truth

Before the pilot even “starts,” we share a clear menu of what onboarding looks like, what we need from the partner, what we own end-to-end, what security considerations exist, how other partners have defined success, and a schedule with checkpoints.

Then we treat those docs as living artifacts. We revisit success criteria weekly, update assumptions as we learn, and make the work legible to everyone involved. This makes sure we’re aligned with our partners while keeping up with the breakneck pace of industry trends.

2. Accuracy: no sandbox theater

One of our biggest differentiators is simple:

There’s no distinction between the pilot and year one.

We deploy into partner clouds and run golden workflows that the partner defines as mission-critical.

To minimize risk, we design deployments so partners can choose their comfort level. Want us hands-off? We guide you. Want us to manage it end-to-end? We do it with full transparency and visibility.

Most partners hand us the keys by week two because they see the value in having experts take the burden off their team while having confidence that we share the same definition of success.

And we’re explicit about what’s happening under the hood:

• Permissions
• Security hooks
• Data access
• Operational boundaries

No hand-waving.

3. Iteration: long enough to learn, short enough to decide

Our pilots typically last 1–2 months. That gives teams time to see the system operate under real constraints, refine what “success” actually means, discover unexpected use cases (or blockers), and evaluate fit without rushing.

And because the integration is real, the transition to a longer engagement is almost unnoticeable for teams building with Crafting.

Honesty as a policy

We actively encourage partners to look at alternatives while evaluating Crafting.

Not because we’re hedging—because we’re confident.

Two reasons:

1. Confidence requires comparison. If we’re the best fit, we want that to be clear.
2. Clarity drives improvement. If we’re not the best option for a core use case, we want to know exactly why.

We’ll even tell partners to use something else when it’s the right answer.

For basic workflows that don’t require:

• enterprise guardrails
• complex infra constraints
• serious governance

…there are simpler tools that work great out of the box.

We believe being trusted and honest experts is the right way to do business and ensure Crafting’s long-term success.

What “good” looks like at the end of a pilot

A successful pilot ends with more than “the demo worked.”

Our partners walk away with a clear internal narrative for champions, a grounded understanding of actual vs perceived risk, evidence of real value in real workflows, and momentum towards a partnership built on trust.

At that point, procurement and the sales process becomes more of a formality than a game of pitching and persuasion. Partners know what kind of value we bring to their company, what it’s worth to them, and how we’ll support them throughout our partnership.

Closing

If you’re evaluating infrastructure for an AI-era engineering organization, you shouldn’t have to choose between:

• a shallow two-week trial
• a couple of demos
• a vendor’s promises

You should be able to see reality early, clearly, and collaboratively.

That’s what our pilots are for.