Built From Your Expertise. Beyond What Expertise Alone Could Reach.

Your domain expertise is the foundation a product gets built on. The collaboration with humans and agents is what takes that foundation and builds it into something you couldn't have produced alone. Neither half works without the other.

A compliance lead at a regional bank walked us through what her job actually looked like. Not the org chart version. The real version. She spent most of her time triaging risk across hundreds of policies, dozens of regulators, and a calendar of audit deadlines that nobody else in the building was tracking with the same precision. She had fifteen years of it in her head. Most of what she did would be impossible to explain to someone who hadn't done it.

She'd tried to build her own internal tool. She'd gotten remarkably far. She had an AI-generated dashboard that looked like a real product. It also organized data the way most compliance vendors organize it, which is exactly the way she'd told us was wrong. She'd unconsciously rebuilt the thing she was trying to escape, because the AI tools she was using defaulted to the structures most existing products use, and she didn't know to push back on those defaults.

When we started working with her, the foundation was already there. Her knowledge of what compliance officers actually need. Her understanding of the audit cycle. Her instinct for what makes a risk worth surfacing. None of that came from us. It came from her, and any version of this product that didn't lead with it would have been a worse product.

What we added wasn't more expertise. It was a way of working that took her expertise and built it into something she couldn't have built alone. Not because she wasn't capable. Because the gap between "the right idea" and "a real product the right idea fits inside" turns out to be vast, and that gap is exactly what the collaboration crosses.

Why is domain expertise the foundation and not the whole thing?

Most of the early conversation about AI and domain experts went straight to one of two endpoints. Either AI was going to replace domain experts (which is silly), or AI was going to let domain experts build their own software without anyone else (which is half right, in a way that hides where the ceiling actually is).

The version we've watched play out in practice is more interesting than either.

Domain expertise is irreplaceable in the work. It's the thing that determines whether the product is right in the small, particular ways that only matter to people who've lived in the problem. A compliance tool that doesn't get the audit cycle correct is not a working compliance tool, no matter how clean the UI is. A logistics tool that doesn't model the actual rules dispatchers operate by is not a working logistics tool, no matter how fast it generates routes. We've been writing about this from a few angles. The closest to the problem should be closest to the build is the pillar version of the argument. Expertise has to be in the work, continuously, for the work to be any good.

But expertise has a ceiling, and the people deepest in their domain are usually the first to know it.

The ceiling shows up in three places, every time. First, in product craft: the discipline of turning what you know into something users can actually navigate, hold, and trust. Second, in breadth: when you're working alone, you see the version of the solution closest to your own mental model, and you don't see the seven adjacent versions that might be better. Third, in speed: an expert working alone, even with great AI tools, can't sustain the pace of iteration that finding the right answer requires.

None of those ceilings are about intelligence or effort. They're structural. They're the parts of building software that don't transfer just because the cost of code dropped. The compliance lead could have spent another year building her tool alone, and she would have produced something better than she had. She wouldn't have produced what we built together, because the gap was never about time.

What does "built from" expertise look like in practice?

Built from is different from informed by. Most consulting and most agency work is informed by the client's expertise. They listen, they translate, they build. The expertise is upstream of the work; once the build starts, the expertise mostly stops shaping it directly.

Built from means the expertise is in every shaping moment. The expert isn't briefing the team and then receding. They're in the room when agents are generating options, with hand on the keyboard, saying "no, that's not how we think about this" while the work is still soft enough to change. We described this dynamic in detail in clients are co-creators. The structural shift is putting the expert next to the work, not adjacent to the team that does the work.

What that looks like in practice is unglamorous. It's the expert pointing at a screen and explaining why the proposed flow won't survive contact with a real user, because she's seen real users freeze at exactly that step. It's the founder catching that the proposed data model treats two cases as the same when his fifteen years of experience tell him they have to be different. It's a hundred small course corrections that no requirements document would have captured because the expert didn't know they were requirements until the work in progress made them visible.

This is what we mean when we say expertise is the foundation. The product gets built on top of the expert's continuous judgment about what's right, not on top of a snapshot of that judgment captured at the start.

What does "beyond what expertise alone could reach" look like?

If the foundation is the expert's knowledge, the building above the foundation is the collaboration. And the collaboration produces three things that an expert working alone, even with the best AI tools, won't produce.

Breadth they couldn't see. A team that's worked across dozens of products in adjacent spaces will spot the patterns the expert is too close to see. Not because the expert is wrong about their domain. Because no one working solo can see the seven adjacent variations of their own thinking. The agents generate breadth at a different scale entirely: ten approaches in the time the expert would consider one. The expert picks. The picking is high-leverage because they've now seen what they couldn't have generated alone.

Craft they don't carry. Product craft is its own deep discipline. Knowing when an onboarding step matters and when it's friction for friction's sake. Knowing how to design for the case where the user is exhausted at the end of a workday and won't read the help text. Knowing where users actually scroll. This is what our team brings. It isn't more important than domain expertise. It's just different from it, and the combination produces something neither side could produce alone.

Speed that catches their thinking before it ossifies. When the expert can see their idea as working software in twenty minutes, they keep iterating. When it takes six weeks, they commit to whatever they said six weeks ago because they don't remember why they thought it. Speed isn't about shipping faster. It's about keeping the expert's thinking alive in the build long enough to find the better answer. We wrote about this from the angle of aim: aim is what speed exists in service of.

The building reaches higher than the expert could reach alone because of these three things, working together, every day, for as long as the engagement lasts.

What does this mean for the kind of expert this works for?

Not every expert wants to be in the work. Some genuinely want to hand a vision to a team and review what comes back. That's a real preference and it works in some engagements. It's not how we work, and the kind of expert this manifesto is talking about is a specific kind: the one who wants to build with, not for.

The compliance lead wanted to be in the work. The logistics founder wanted to be in the work. The financial advisor whose paralyzed-client insight reshaped a whole product wanted to be in the work. The fact that they wanted to be in it was non-negotiable to the outcome. We've taken on a few engagements over the years where the client preferred to hand the vision over, and those engagements produced fine software, but they didn't produce what the deep collaboration produced.

This is the model. Built from your expertise: the foundation has to be the knowledge you've spent years accumulating. Beyond what expertise alone could reach: the collaboration with humans and agents takes that foundation and produces something more complete than you would have produced on your own.

Neither half works without the other. Expertise without collaboration ceilings out. Collaboration without expertise has nothing to build on. The two together produce software that looks like the expert's mind, executed with the craft they couldn't have brought themselves, at the speed nothing in the old way of working would have allowed.

That's the building we're after. Not for them. With them.