What did Michael Preuss contribute to Blaxel's customer stories?

I led the customer-story program at Blaxel, wrote the technical drafts, built companion examples and prepared distribution copy and release plans. The stories explained what customers were building, how their architecture worked and where Blaxel fit.

Why pair a Blaxel customer story with a GitHub cookbook?

A Blaxel customer story explains the architecture and its purpose. A companion cookbook gives developers a smaller mechanism to inspect, run and adapt. It is a reference example, not the customer's production code.

What do the Blaxel cookbooks demonstrate?

The Blaxel Agent Drive lifecycle cookbook demonstrates retaining files after one sandbox is deleted and reading them in another. The sandboxed code generation cookbook demonstrates building, checking and updating code in a retained working environment, with a fuller reference for repair and recovery.

How was distribution planned for Blaxel's customer stories?

I planned Blaxel's customer-story releases around each customer's strongest channel, a supporting company-site version and social copy for both teams. The collection was planned in two release waves, with approvals, visuals and tracking links prepared as part of the package. This describes the release plan, not a claim that every draft was published.

Blaxel Customer Stories & Cookbooks

Start with what the customer built

I led the customer-story work at Blaxel and wrote the technical drafts. I wanted a developer reading them to understand what the customer was building, how it worked, and where Blaxel fit.

That meant explaining the architecture. Which system held the source of truth? What happened when an agent stopped running? Where did files, dependencies and credentials live? What did the customer own, and what did Blaxel operate?

Those questions made the stories useful beyond a customer name and a testimonial. They gave a technical buyer enough detail to judge whether the same approach could work in their own product.

In the Webflow story, Webflow keeps the component's durable source and product state. Blaxel supplies the environment where generated code is built, checked and repaired.

A user asks for a component

Product

Webflow

Generate and save the source

Webflow sends a working copy into the Sandbox.

Durable source + product state

Webflow to Blaxel: Source files

Blaxel to Webflow: Compiled component

Execution

Blaxel Sandbox

Build and check the code

The Sandbox installs dependencies and runs build, lint and type checks.

Working files + dependencies + processes

Build Webflow retrieves the compiled component and mounts it in Component Canvas.

A simplified view of the architecture in my Webflow technical-story draft.

Turn the mechanism into something runnable

Where a runnable example added proof, I paired the story with a companion GitHub cookbook. The example isolated the part another developer could reuse, without presenting it as the customer's production code.

Two examples show the approach:

Keep files when compute goes away. The Agent Drive lifecycle cookbook writes an artifact, deletes the sandbox that created it, then mounts the same drive in a new sandbox and reads the artifact back. The example makes the separation between temporary compute and durable files visible. Its README includes the access prerequisites for running it.

Keep a working environment through an edit. The sandboxed code generation cookbook takes generated code through a build and preview, then updates a component in the same environment. The retained files and dependencies make continuity something a developer can check. The fuller reference covers validation, repair and recovery.

The story explains why that behaviour matters in a product. The cookbook lets someone inspect the smaller mechanism for themselves.

Plan the story's route to the reader

I planned customer-story releases around the customer's strongest channel, with a supporting version on Blaxel's site and social copy for both teams. The customer version would explain what they'd built. The Blaxel version would explain the infrastructure and point to the example.

The release plan grouped the collection into two waves, with customer approvals, visuals, distribution copy and tracking links prepared as part of the package. This was release preparation; it doesn't mean every draft in the collection was published.

What I contributed

Writing the stories, building companion examples and preparing distribution gave the same work several uses: a developer could learn from the code, a technical buyer could inspect the architecture, and Sales had concrete material for a conversation.

The product-launch work used the same principle: explain the product through a task the reader can follow, then give them a useful next step.

Customer Stories & Cookbooks