Building the Framework and the Software at the Same Time

A few years ago, if you had told me I would be co-building a coaching program for creative agencies, I would have been polite about it and changed the subject.

Coaching, in the form I had seen it in my agency years, looked like a clean way to package selling-yourself-as-the-product. Someone had done some interesting work, written a book, and turned the back end of that work into a program that other people paid to be inside. The program was usually a wrapper around the personality of the coach. It worked or did not work depending on whether the coach was actually good at what they claimed to be good at. Some coaches were. Many were not.

What I was wary of, specifically, was the gap I kept noticing between the methodology coaches sold and the methodology they appeared to actually use. The marketing version was always cleaner than the operating version. The framework on the website implied a structured process. The actual sessions, as far as I could tell from the agencies I knew who had been through them, were mostly conversations with a smart person about the agency's situation. Useful conversations, sometimes. Not the same thing as the productized framework that was being sold.

That gap is part of why Peter, my business partner at ClockWork League, and I have ended up building what we are building.

Two backgrounds that do not overlap

We started working together eight months ago. Peter's background is corporate. Seven-figure to nine-figure businesses. Capital raises in the hundreds of millions. Global teams. The kind of operational discipline that a certain category of business takes for granted and a certain category of business does not.

My background is the opposite. Small-to-mid-size digital agency, twelve years, scaled to thirty people, and learned everything the hard way. The kind of business where the founder is involved in too much for too long, where systems are usually missing, where the gap between what the business says it does and what the business actually does is often significant.

These two backgrounds turn out to be complementary in a useful way. Peter has the operational discipline that comes from running businesses with proper financial, leadership, and strategic infrastructure. I have the lived experience of running businesses without any of that. He has seen what good looks like at scale. I have seen what stuck looks like up close.

We started talking about what would actually help creative agencies. Not the generic advice. Not the agency-growth tactic of the month. The structural work that would let those agencies move from where they are stuck to where they want to be.

The conversation kept turning into a methodology. Then it kept turning into software.

Neither of us planned to build either of those things. Both of them emerged from trying to answer the same question carefully.

Software refuses to accept fuzzy

The interesting thing about building a methodology and the software for it at the same time is that the two activities have different kinds of integrity.

A methodology that exists only in conversation can stay fuzzy. It can drift. It can be different in different sessions. It can be defended in retrospect with vague language about how every agency is different. Coaches who only work in conversation can hold methodologies that sound coherent without actually being coherent.

Once a methodology has to inhabit software, it cannot do that. The software refuses to accept fuzzy. Every concept has to be defined. Every assessment has to be scoreable. Every decision rule has to be specified. Every relationship between concepts has to be expressed in fields, statuses, and transitions that the system can act on.

This is uncomfortable, but it is also a forcing function for honesty. Building the software has repeatedly made us notice places where the methodology was not as clear as we had assumed. Sometimes those places had been hidden by experienced-sounding language. Sometimes they had been hidden by the fact that the methodology had not yet been tested in the situations that would have surfaced them. Either way, the software exposed them, and we had to do the work of clarifying.

The reverse pressure is also useful. The methodology has to make sense before the software is worth building. Software built on a weak methodology produces a weak product, no matter how good the engineering is. We have refused to build pieces of the platform whose methodological foundation was not yet solid. The discipline of having to defend each capability methodologically has kept us from building things that looked impressive but did not actually serve the user.

Together, the two systems hold each other accountable.

Two people building in different directions

There is also a partnership dimension to building this way that I want to talk about, because it is not always obvious from the outside.

Peter and I are doing very different work day-to-day. He is doing most of the customer-facing development of the methodology, the workshops, the conversations with agency owners, the testing of frameworks in real situations. I am doing most of the building of the platform that will eventually carry the methodology, plus the AI architecture, plus the systems thinking about how the pieces fit together.

These two domains touch each other constantly. A finding from a customer conversation changes a piece of the platform's structure. A capability of the platform suggests a new question for the methodology. A decision about how to handle assessment scoring becomes a methodological commitment. A methodological commitment becomes a software constraint.

Neither of us can do the other's work. Neither of us would want to. But the fact that we are both building at the same time means the methodology and the software develop with a tightness that would be hard to achieve if one of us was building while the other was waiting.

The risk of working this way is that both of us are operating slightly outside our previous experience. Peter has not built software before. I have not run a coaching program before. We are each at the edge of what we know in different directions, which means we lean on each other for the parts where the other has more competence.

In return, what we end up with should not look quite like anything either of us would have built alone. Peter, alone, would have built a coaching practice. I, alone, would have built a piece of software. Together, we are building something that is meant to be both - and the both-at-once is where the interesting design questions live.

I am writing about this partly because building in public is part of the project, and partly because I think the pattern is going to become more common.

Why this work usually needs a partnership

Expert services are increasingly going to be delivered through structured software rather than pure consulting. The pattern is already visible in legal, in medicine, in financial advice, in design. The expert does not disappear. The delivery shape changes. Someone has to do the translation work between the expert practice and the software that carries it.

The people best positioned to do that translation are usually partnerships, not solo founders. The methodology side needs deep domain expertise - years in the field, a clear point of view, a willingness to take positions. The software side needs deep systems thinking - architecture, AI, data modeling, the discipline of translating fuzzy concepts into structured environments. Both sides need each other.

Finding someone you can build that kind of project with is not easy. We were lucky that the conversation Peter and I started having matched naturally. The partnership came before the project. The project is what the partnership decided to build.

That order matters. I have seen many founders try to find a co-builder for a project they had already decided to do. It usually does not work, because the project is the wrong starting point. The right starting point is two people who can hold the same problem from different angles and who actually want to spend years working it out together. The project emerges from that. Not the other way around.

We are about eight months in. The methodology is significantly clearer than it was when we started. The software is starting to take real shape. Neither of them is finished, and neither of them will be finished for a long time. The work is the work.

What I can say already is that building both at the same time has been the most interesting thing I have worked on in years. The reasons are not the obvious ones. It is not the software. It is not the methodology. It is the back-and-forth between them, and the partnership that makes the back-and-forth possible.