The DWY Delivery Framework — What a Session Actually Looks Like
The theory of done-with-you is clean: the client does the work, you steer. In practice, "the client does the work" requires a session structure tight enough to keep progress moving and loose enough to accommodate the reality that your client is learning in real time. Without that structure, sessions drift — they start late, they wander into tangents, the client gets stuck and you instinctively take over, and by session three you're doing done-for-you work at done-with-you prices.
This article is the minute-by-minute breakdown. What happens before, during, and after a DWY session. The structure isn't a suggestion — it's the delivery mechanism. Skip it and the engagement degrades in predictable ways.
Pre-Session: The Prep Doc
Every session starts before the session starts. The client receives a one-page prep doc 48 hours in advance. Not a syllabus — a checklist. "Before we meet, have X account open, Y data exported, and Z document accessible. If any of these aren't ready, let me know now so we can adjust."
The prep doc serves two functions. First, it eliminates the most common session waste — the first 15 minutes spent watching someone log into accounts, find passwords, and download files they should have had ready. Those 15 minutes, multiplied across four sessions, are a full hour of paid time spent on administrative friction. The prep doc moves that friction to the client's own time, where it belongs.
Second, the prep doc is a compliance test. How the client responds to it tells you what the engagement will be like. The client who has everything ready on time will do their homework between sessions, follow the session structure, and respect the boundaries. The client who shows up without having read the prep doc — or worse, shows up and says "I didn't have time to do any of that" — is signaling that they treat your sessions as the only time they'll engage with this project. That client needs a different conversation before the next session, because no amount of good delivery compensates for a client who won't prepare.
The prep doc should be specific enough to be actionable and short enough to be read. One page. Bullet points. No preamble. If it takes more than five minutes to read and understand, it's too long.
The First 10 Minutes: Orientation
The session opens with three things, in order.
First, a review of what happened since last session. Did they complete the homework? Did they run into problems? Did anything change in their setup or priorities? This is a five-minute check-in, not a therapy session. You're looking for blockers — technical issues, misunderstandings, things that broke after you last spoke. If there are no blockers, you move on fast. If there's a blocker, you decide in real time whether to address it now or note it for later in the session.
Second, a statement of the session goal. One goal, stated out loud. "By the end of this session, you'll have a working n8n workflow that takes a content brief and produces a first draft." Not three goals. Not a vague direction. One concrete deliverable that both of you can point to at the end and confirm is done. Saying it out loud matters — it creates a shared contract for the next 60-80 minutes and gives you a tool for redirecting when the conversation drifts. "That's a good question, but it's outside today's goal. Let's note it for session four."
Third, any housekeeping. Screen sharing setup, recording permissions, tool access confirmations. This should take under a minute because the prep doc already handled the logistics. If it's taking longer, the client didn't do the pre-work, and you're already behind.
The Working Block: 40-60 Minutes
This is where the value lives. The client shares their screen. They do the work. You direct.
The fundamental rule of the working block is: you do not take over. The moment you say "let me just drive for a second" and start clicking through their screen or sharing your own to "quickly set something up," the engagement shifts from DWY to DFY. The client's learning stops. Their hands stop. They watch you work instead of building the muscle memory of doing it themselves. And when you hand control back, they're more confused than before — because watching someone else navigate a complex interface teaches you almost nothing about navigating it yourself.
This rule is hardest to follow when the client is stuck. They're fumbling with a configuration panel, clicking the wrong tabs, getting error messages they don't understand. The instinct to take over is overwhelming — you could fix this in 30 seconds, and watching them struggle for five minutes feels like a waste of session time. It is not a waste. That five minutes of struggle — with your guidance — is worth more than five hours of you configuring things on their behalf. The struggle is where learning happens.
When they're genuinely stuck — not "I need a moment to think" stuck but "I have no idea what I'm looking at" stuck — use the show-then-hand-back technique. You demonstrate the action on a separate example, not on their actual project. Open a different account, a test environment, a blank workspace. Show the sequence of steps. Explain what each step does and why. Then switch back to their screen and say "now you do it." They replicate what you just demonstrated, on their own project, with their own hands. The replication is the learning. The demonstration is just the setup for it.
The reason you never demonstrate on their actual project is that it converts the demonstration into delivery. If you configure their real n8n workflow while "showing them how," you've done the work. They haven't. And the difference becomes obvious in session four when you ask them to replicate or modify what was built — and they can't, because they didn't build it.
Pacing in the working block requires active management. Some clients move too fast — they click before thinking, skip instructions, and create problems you'll spend 10 minutes fixing. Others move too slowly — they read every tooltip, second-guess every choice, and progress stalls. For the fast clients, slow them down by narrating: "Before you click that, tell me what you think it does." For the slow clients, set micro-deadlines: "Let's get this configured in the next five minutes, and if we hit a snag, we'll troubleshoot it then."
A good working block feels like pair programming. You're the navigator, they're the driver. You see the big picture and call out the next turn. They handle the mechanics of execution. Neither of you could do the session alone — they don't know the route, and you're not touching the steering wheel. That division is the product.
The Last 10 Minutes: Close and Assign
The close is where most DWY operators lose value. The working block runs long, the session bumps up against the time limit, and the close gets compressed into "great session, talk next week." That's a failure — not a dramatic one, but a slow leak that makes every subsequent session less effective.
The close has three components. First, a recap of what was accomplished. Not a general summary — a specific statement. "Today you configured the n8n workflow that connects your CMS to Claude for draft generation. It's working. You tested it with two content briefs and both produced usable output." This recap crystallizes the progress in the client's mind. Without it, they walk away with a vague sense that "stuff happened," and by next session, they're not sure what they built or what state it's in.
Second, homework. Not optional homework — required deliverables that set up the next session. "Before our next meeting, I need you to run the workflow five more times with different briefs and note any failures in our shared doc." The homework has two purposes: it gives the client practice with what they just learned, and it surfaces problems while you're still available to help. Problems discovered between sessions can be addressed in async support. Problems discovered in session four — when they should be minor — burn live time.
Third, expectations for next session. "Next time, we'll integrate the email notification step and set up the error handling. Have your email service provider credentials ready." This primes the client for what's coming, reduces anxiety about the unknown, and makes the next prep doc feel like a continuation rather than a cold start.
Record the session. With the client's permission, which you obtained in session one, record every working session. The recording is not a nice-to-have — it's a core deliverable. Clients who can rewatch a session while doing their homework learn roughly twice as fast as clients working from memory alone [VERIFY — based on general spaced repetition and video learning research, not a specific DWY study]. The recording also protects you against "you never showed me that" conversations. You did. It's on tape.
Between Sessions: Async Support
Between sessions, the client has access to a shared document or Slack channel for questions. This access is time-boxed — 15 minutes of your time per day, maximum. Not 15 minutes of "being available" — 15 minutes of actual response time. You check the channel once per day, respond to what's there, and close it.
The time box is the boundary. Without it, async support expands to fill every available hour. "Quick question" becomes six questions. A Slack message at 9 PM becomes an expectation of 9 PM availability. The 15-minute cap prevents this — when the client knows your async time is limited, they self-filter. They ask the questions that actually matter and solve the small ones themselves. That self-filtering is itself a form of skill transfer.
For questions that require more than a text response, use short screen-recorded videos — Loom, or whatever your tool of choice is. A 2-3 minute video showing how to navigate a specific configuration panel replaces a 15-minute back-and-forth in text. It's faster for you, clearer for them, and reusable if the same question comes up with a future client.
The Final Session: Graduation
The last session is structurally different from the others. It's not a working session — it's a verification session. The deliverable is already done. The question is whether the client can maintain it independently.
The final session has three parts. First, the client walks you through the entire system they built. Not you walking them through it — them showing you. Screen share, narration, explanation. "This is the workflow, here's what triggers it, here's where the output goes, here's how I'd modify it if I needed to change the content format." This walkthrough reveals gaps. If they can narrate the system confidently, they own it. If they stumble, you identify the specific gaps and address them on the spot.
Second, you introduce a hypothetical change. "What if you wanted to add a second content type to this workflow? Walk me through how you'd do it." This tests not just their understanding of what you built together but their ability to extend it — which is the real measure of skill transfer. If they can reason through a modification they haven't seen before, the engagement succeeded. If they freeze, you have ten minutes to close the gap.
Third, documentation. You provide a written reference — not a manual, but a one-page cheat sheet covering the key configuration points, the most common failure modes, and where to look first when something breaks. This cheat sheet, combined with the session recordings, is the client's safety net after you leave.
The final session should feel like a graduation, not a goodbye. The client built something real, they understand it, and they can maintain it without you. That independence is the product. Everything else — the sessions, the homework, the async support — was just the delivery mechanism.
This is part of CustomClanker's Done-With-You series — turning AI skills into client revenue.