AI Library
Books for Reading AI
Choose a book, then read it in order from the table of contents.
[AI Library] Chapter 35: Workflow Validation, QA, and Handoff
Mastering Claude Code
Chapter 35: Workflow Validation, QA, and Handoff
Kim Kyung-jin
Mastering Claude Code
Principles of Quality Assurance Before Deployment
Your workflow is complete. All nodes are connected, and when you feed in a test case or two, results emerge. "Great, it works!" The relief at this moment is deceptive. Deploying a workflow validated with just one or two test cases to production is like taking a new car around a parking lot and then driving it onto the highway.
Quality assurance before deployment,QA,protects your workflow from breaking under real conditions. Skip this step, and your reputation as a consultant takes a direct hit. Pass off a buggy system, and your client's trust collapses. Rebuilding trust takes many times more effort than building it the first time.
QA begins by planning validation data together with your client. You don't want arbitrary fake data. Request sample data that resembles real use: emails, customer support tickets, CRM records, call logs,data in the same form your workflow will handle in production. If privacy is a concern, anonymize it.
Once you have the data, agree on success criteria. Define what good output looks like and what must never happen.
That one step gives your client the impression of professionalism. Most people just say, "It's done, try it out." Guiding the QA process first sets you apart.
Stress Testing: The Mindset of Designing for Failure
Move beyond checking each node one by one like a developer. Shift to the engineer's mindset: design for failure.
Automation,especially when AI is involved,will always encounter unpredictable situations. Once in production, real users and real data will create edge cases you never imagined. During validation, ask yourself this:
You cannot eliminate every possible problem. Your goal is different: make the system fail quietly and safely when problems do occur. Set timeouts to prevent infinite waits. Add error handling that alerts you when something breaks. Log failures automatically to a spreadsheet so you can track patterns.
[Figure 35-1] Stress Testing Scenario Matrix
On this foundation, conduct black box testing. Treat the workflow as a single box. Feed it many sample inputs,not one or two but dozens, ideally hundreds. For each input, record three things: what went in, what happened in the middle, and what came out. Then compare each output against the success criteria you agreed on with your client.
Flag failures, odd results, and edge cases. This is your internal QA pass. The goal is to catch as many problems as you can before your client touches the system. Internal QA should run for at least a few days.
An Additional Layer: AI Quality Review
If your workflow includes AI, there is an additional review dimension. Check not just that the AI node runs, but that its output is actually good.
Relevance and accuracy: Is the AI's response actually answering the question asked? Is the information correct?
Tone and safety: Are there any inappropriate or off-brand phrases? Is the system prompt or internal information leaking out?
Consistency: When you feed the same input ten times, do you get roughly the same quality of response?
Behind the scenes, you can run A/B validation and evaluation. Apply different prompts and models to the same dataset and track which combination produces the best results.
Explaining this to your client establishes you not as a simple builder but as a systems engineer.
The Importance of Logging
Logs are your QA evidence. Save a record of each workflow run to Google Sheets or similar, tracking inputs, outputs, tool calls, errors, and token usage. Through these logs, you can identify recurring failure patterns, frequent bad inputs, and weaknesses in your prompt or model choices.
Logs become your proof when talking to your client. You can show them data and say, "We tested this, got these results, and made these improvements because of what we found."
[Figure 35-2] Example QA Log Spreadsheet Structure
Handing Off to Your Client: The Craft of a Professional Handover
Once internal QA is done, move to client-facing QA. Give your client a clean interface to validate the system. For a chatbot, that might be a chat window. For a data workflow, an input form. The key: do not show them the internal machinery. What they need to see is the result.
Ask for feedback on accuracy, tone, and format. If everything has gone well up to this point, revisions will be minor,a matter of prompt tuning or small adjustments to the model. Go through rounds of this: incorporate feedback, run internal QA again, check with the client again.
In the final stage, record a short walkthrough video. Show one or two complete end-to-end runs,from input through workflow processing to final output,while pointing to the logs and explaining how the system handled real data.
Once QA is complete, you enter the handover process. The shape of your handover depends on two factors.
Where you built: If you built directly in your client's environment, the handover is relatively clean. Everything is already in their infrastructure. If you built in your own environment, you need extra work: transferring credentials, resetting connections, and so on.
What comes next: Whether the project is done or more work and maintenance are planned shapes how complete the handover needs to be. If you are staying on, you can keep the validation infrastructure in place. If you are leaving, the handover must be final and complete.
Essential Handover Checklist
Workflow duplication: Separate production from backup and validation. This follows the same principle software teams use to split development from production environments. Test any changes or updates on the validation version first, then push to production.
Backups: Export the workflow to GitHub, Google Drive, or similar so you can roll back to earlier versions. Build in an automatic backup process if you can.
Workflow cleanup: Name each step clearly. Use notes to explain the logic. Anyone looking at it later should be able to understand the structure immediately.
Sensitive information removal: Do a final check for any API keys or tokens sitting in plaintext inside the workflow.
Video guide: Record a 1-2 minute screen capture showing how the system works, how to configure it, and what to check when updates are needed.
Documentation: Write a document explaining the logic behind the workflow design. After you leave, this becomes the guide for someone on the client team or a new developer taking over.
[Figure 35-3] Full Handover Checklist Diagram
Turning the Handoff into a Long-Term Relationship with Maintenance
Once handover is complete, you reach the project closure phase. This is where two things get resolved.
Finalizing billing: Retrieve the originally agreed Scope of Work and confirm together that each item has been completed. Once the client confirms project completion, send the final invoice. "The agreed workflow has been built, validated, documented, and handed off. The final invoice is issued."
Discussing maintenance contracts: A retainer is a separate contract from the project fee. It includes bug fixes, minor adjustments, dependency updates, monitoring, and basic security checks. New features, new workflows, and large-scale scope changes are not included. These are separate projects.
Set Service Level Agreement (SLA) expectations briefly. Urgent issues are addressed within hours, general requests within days. Complexity is not necessary, but expectations must be clear.
Clarify ownership and intellectual property (IP) rights. In most consulting contracts, deliverables become client property after payment. However, the consultant should protect rights to reusable patterns, general-purpose tools, and base templates.
Define the exit process as well. Agree in advance on what is handed off when the client terminates service, what is included and what requires additional payment.
[Figure 35-4] Workflow from project completion through maintenance contract to expansion project transition]
The most important principle for beginners is this: stop working informally. Put scope, definition of done, fees, maintenance, service levels, the distinction between bugs and changes, ownership, and exit conditions in a written contract. When both sides understand what they are buying and what happens next, projects flow smoothly and misunderstandings decrease.
When you execute this entire process,building, validating, handing off, maintaining,professionally, a one-time project transforms into a long-term relationship. The deeper the relationship, the better you understand the client's business, and that understanding becomes your competitive advantage. You become a partner that is hard to replace.
Once a partnership that began in warmth stabilizes, it is time to broaden your vision. The next challenge is learning when and how to strategically use cold outreach,the method of moving beyond your warm network into unfamiliar markets.
Kim Kyung-jin, Expert in Artificial Intelligence and Attorney
Specialist in AI law and policy · Former member of National Assembly · Author of multiple works
If this book has been with you even briefly, please support the publication of the next story.
(Voluntary support account: Nonghyup 302-1096-0948-81 Account holder: Kim Kyung-jin)
Kim Kyung-jin
Attorney · Former Member of the National Assembly · AI Policy Researcher
© 2026 Kim Kyung-jin. All rights reserved.