Buried, Built, Reborn

Why this next chapter — for me and for AI consultants — starts with what came undone.

It’s been a while. Not just since my last newsletter, but since I last surfaced with clarity.

The reason? I’ve been buried in the work.

Deep in the build with my team at Plumb, trying to get to the core of who we’re really building for and what they actually need.

It wasn’t just about adding features—it meant letting go of ideas, rethinking what we assumed, and rebuilding from a more honest place.

That process cracked some things open. Now that we’re on the other side of it, I’m ready to write again—with more clarity, more focus, and a better sense of why it matters.

Why I Haven't Written

When you're buried in the build, it's easy to lose sight of the bigger picture—or just stop talking altogether.

That’s been me for a while. But lately, something’s shifted.

We’ve come through a messy, necessary phase of figuring things out—what we’re building, who it’s really for, and what we’re trying to make possible.

Now that it’s clearer, I want to start writing from that place.

Not just sharing updates, but exploring the bigger themes behind the work: clarity, trust, systems that scale human effort, and what it actually takes to support AI consultants (and anyone building for AI at scale) doing meaningful work.

This next stretch of writing won’t be about keeping up a content habit.

It’s about sharing what I (and sometimes the team) have been learning in the open—so it’s useful, relevant, and hopefully energizing for people walking a similar path.

The Big Shift: AI Consultants Are Transforming Everything

The biggest realization we've had: we're building the operating system upon which an entire generation of AI consultants are going to transform the world.

If you've ever done consulting work with AI and automation, you know the pain points.

You build something amazing for a client, but then updates become a nightmare. Version drift happens. Clients can't make changes without breaking things. You end up spending more time maintaining than building.

What we're seeing is that AI consultants need infrastructure that lets them focus on the high-value work—understanding client problems, designing solutions, and delivering results—not wrestling with deployment and maintenance.

The "Anyone Can Cook" Problem

Early on, we tried to build for everyone—the "anyone can cook" model.

But here's what I've learned: building robust workflows, especially with AI, requires some technical know-how. AI is great at happy paths, but as soon as you hit complexity or edge cases, you need someone who understands how things work under the hood.

AI is generally lazy and will take the path of least resistance. Unless you know how to ask really well for requirements, you're going to get basic, average workflows.

So we're building for consultants and technically savvy builders—people who can think programmatically and understand when something isn't quite right.

Two Different Experiences for Two Different People

One thing we learned: builders and end users need totally different experiences.

The builder interface is for people who think programmatically—it's nodes and edges, directed acyclical graphs. Most people find this terrifying to look at (and to change!), and that's okay.

The runner is for end users—clients—who just want to use the workflow without ever seeing the technical complexity. They get forms, simple triggers, and a cozy interface that doesn't scare them away.

This separation has been huge for usability and reducing churn.

What We've Been Building

I've been focused on adding constraints to prevent what I call "foot guns"—places where you can shoot yourself in the foot.

For example, a filter node should only accept a collection, not a string. These guardrails make building safer and less error-prone.

I’m focused on making things easier to fix and harder to break.

Pete, our design engineer, has been making the step configuration beautiful and intuitive. Every step is defined as a schema, and we dynamically generate the UI, so adding new functionality is fast and consistent.

Tyler, our backend engineer, has been working on making integrations smarter. When a client subscribes to your workflow, they can easily map it to their own data sources—their Notion database, their Google Docs, whatever they use.

We've also built unified dashboards and consultant-client workspace features so consultants can manage everything without hacking around permissions.

This is just what our product team has been building. It doesn’t even touch the massive amount of work our brand, marketing, sales and product direction team has been up to.

The Subscription Model That Actually Works

Here's the key insight: consultants can build a workflow once, and clients can subscribe to it with their own personalization.

When the consultant updates the workflow, subscribers get a button that says "update now." They can pull in the new version with a click, or roll back if needed.

This means consultants can deliver constantly improving solutions without the usual friction of distribution and maintenance.

What's Next for Me

I'm going to start writing more about the technical concepts behind this work—things like determinism in AI, human-in-the-loop workflows, the difference between productivity and effectiveness…the things I’m mired in every day.

I want to get into the weeds, share what I know at the level I know it, and build community with others who care about these topics.

If I'm wrong about something, I want to hear about it. If you're building in this space, I want to connect.

I'm going to talk about what I know, how I work, and the workflows that make me more effective.

This newsletter will be about the things I'm learning while building infrastructure for AI consultants who are transforming how work gets done.

Oh, and a Podcast Is Coming

I’m co-hosting a podcast with my co-founder and friend Aaron Dignan: AI Builders Club.

It’s for people building with, around, and through AI—consultants, operators, product folks, and anyone trying to turn messy workflows into something powerful and repeatable. It’ll be casual, real, and full of lessons from the field.

More soon.

A Workflow That Wrote This Newsletter

Funny enough, this very issue started as a voice memo I recorded while waiting for my daughter while she was in art class.

I’ve been experimenting with a workflow in Plumb that lets me speak freely—unedited, rambling, in the weeds—and automatically turn that into a structured draft.

Here’s how it works:

• I record a voice memo on my phone

• I email it to a special workflow in Plumb

• That workflow grabs the audio, transcribes it, and sends it through a language model

• The model generates a draft newsletter, plus a list of unused content I might want to keep for later

• It all gets pushed into my Notion database—ready for editing

It took me about 10 minutes to build the whole thing. And now it’s part of my creative toolkit—a way to turn unstructured thought into something I can ship.

I recorded a quick walkthrough if you want to see it in action:

If this kind of thing is useful to you—or you want to play with it yourself—let me know. Happy to share it.

So What does next week have in store? We’re diving into why telling AI not to do something is often the fastest way to make it do exactly that. Yes, pink elephants and black flamingos are involved.

Thanks for sticking around. More soon—this time, for real.

—Chase

Scraps Worth Saving

There were a number of topics in my voice memo that didn’t make the cut!

If you’re interested in hearing me talk about any of these topics, all I need is for you to leave me a comment comment with the text in bold.

• Podcast pivots history - The detailed history of the podcast pivots (from 'Could AI' to 'AI Builders Club'), including the reasoning behind each shift and the target audiences.

• Zod, metadata & schema deep dive - The technical deep dive into how Zod, Zod metadata, and meta JSON schema work together, and the translation layers between them.

• Real estate agent experiment - The specific example of building for real estate agents and the feedback from that experiment.

• ‘Magic mode’ for non‑technical users - The discussion about the 'magic mode' concept and why it didn't work for non‑technical users.

• Las Vegas retreat insight - The mention of the retreat in Las Vegas where the team had the realization about serving consultants instead of influencers (and influencers instead of a non-technical general crowd).

• Automated newsletter workflows - The plan to use workflows to automate newsletter production (e.g., sending a recording to a mail hook, generating outlines and summaries automatically).

• Board meeting & team dynamics - The reflection on board meetings and internal team dynamics during the pivot process.

• Build vs. buy vs. manual - The intention to write about when to build vs. buy vs. keep doing things manually.

• Finding focus for the newsletter - The personal reflection on finding clarity and focus for the newsletter after a period of uncertainty about what to write.