What Does It Mean for the Client to Build It Themselves?
Litmus is a roughly 60-person company doing e-commerce data-analytics solutions and outsourced development. On the Howwhy AI podcast, CEO Kim Eung-jin introduced something called the 'Partner Platform,' and this is where the substance of 'the client builds it themselves' becomes clear.
On the Partner Platform, the client clicks and selects the element they want changed on their own service screen (a button, a phrase, a layout) and leaves a comment. Write 'change this part like so,' and that comment immediately becomes a 'ticket.' A ticket is a single unit of work—think of it as one development request slip.
Once a ticket exists, an agent attaches to it. An agent is an AI program that reads, edits, and even deploys code in a person's place. At Litmus, an agent named CRH confirms the request, edits the code, and flips the work to 'done.' From the client's side, without having to verbally ask a developer, just clicking and commenting on the screen keeps development rolling. In effect, the client develops it themselves.
Why a PM Gate Is Needed—A Communication Tool, Not Pure Self-Development
But there is a safeguard here. In the early stage, an agent can run tickets as soon as they arrive, but as a project moves into its middle and late stages, a PM (project manager) holds the gate. A gate is a checkpoint where a person decides whether something passes.
The PM looks at a ticket and picks one of three: ship it straight away, ship it after review (a preview via PR), or block it and hold. PR stands for Pull Request—a preview procedure that, instead of applying a code change immediately, first shows 'here's what I'd change; is that okay?' Litmus gates work by not merging a ticket immediately but switching branches and raising a PR.
Why must anything be blocked? Because a client wanting something doesn't make it right. Outsourced projects today are three times more complex than a year ago at the same price, and requests that are technically feasible but out of step with policy or business goals come up often. Filtering, cutting, or adjusting those is still a human's job. So this platform is less a 100% self-development tool and more a tool where the client and the dev shop communicate while looking at the same screen.
The Choice Not to Build 100% of the RFP
Watching this structure, I (SH Consulting) grew sure of my own approach. RFP stands for Request For Proposal—the proposal request and requirements document in which a client lays out 'please build something like this.' Usually a dev shop implements 100% of what's written in the RFP and hands over a finished product.
I deliberately don't do that. I build the core 80% so it runs on its own, and leave the remaining 20% for the client to finish themselves. Build it all for them and the client has to call the dev shop for every trivial change, and that dependency piles up as time and cost.
Here, 80% means 'up to a skeleton that runs on its own.' The remaining 20% (detailed wording, screen fine-tuning, adding a new item, and the like) is left as territory the client can touch themselves. It is not handing over a finished product, but handing over a living system the client can take over and grow.
Why AX Training Replaces the Finishing Work
For the client to do the remaining 20% themselves, they need to know how. So I provide AX training alongside. AX stands for AI Transformation—reshaping the way an organization or individual works around AI. Here it means learning 'how the client fixes and maintains their own service with AI tools.'
Concretely, I get the client's hands used to the flow of fixing screens, changing wording, and attaching simple features with AI coding tools like Claude Code or Codex. It's the same principle as Litmus handing its clients the Partner Platform (click → comment → ticket): instead of verbally asking a developer, it opens a path for the client to touch things directly.
The effect is a shift from dependence to self-reliance. Build it all for them and the client calls me every time; teach them to build it and they run it with their own hands. Maintenance costs drop, and the client becomes the owner of their own service. Then the dev shop becomes not a 'finished-product vendor' but a 'teaching and design partner that makes the client self-reliant.'
In the AI Era, Where Does a Consultant's Worth Move To?
As AI writes code better and better, development itself is becoming a common ability. It's an age where the client can develop directly with AI too. Then what a dev shop sells has to move from 'labor that writes code' to something else.
There are two places it moves to. The first is judgment—the gatekeeper role of deciding what to ship and what to block, which requests fit the business goal and which are risks. The second is teaching—making the client able to do it themselves. Both are territory AI can't stand in for, requiring human and domain understanding.
The Litmus CEO saw the distinction between sales, PM, and developer disappearing, all merging into a single job called 'consultant.' I see the same direction. Execution is handed off to AI and the client; the person rises into judgment, gating, and teaching. In your own work too, try separating 'execution' from 'judgment.' Automate or delegate execution, and keep yourself where the judgment is—that is the survival design for the AI era.