Skip to main content
Lesson 5 of 5 25 min

Client Education

Teaching the principles while delivering work.

Client Education

The Principle

Teaching the principles while delivering work.

The best service leaves clients more capable than it found them. This isn't just about handoff—it's about building understanding throughout the engagement.

Why Education Matters

For the Client

  • Better decisions after we leave
  • Reduced dependency on vendors
  • Ability to maintain and extend
  • Understanding, not just assets

For the Relationship

  • Trust through transparency
  • Partnership, not servitude
  • Long-term alignment
  • Referrals and repeat business

For the Work

  • Faster approvals
  • Better feedback
  • Fewer misunderstandings
  • Smoother transitions

Education is not overhead—it's investment.

Education Throughout the Engagement

During Discovery

Teach while learning:

Client: "We need a mobile app"

WORKWAY: "There are three approaches—let me explain each:

1. Native apps (iOS/Android separate)
   - Best performance
   - Highest cost (2x development)
   - App store requirements

2. Cross-platform (React Native, Flutter)
   - Good performance
   - Single codebase
   - Some platform limitations

3. Progressive Web App
   - Lowest cost
   - Works everywhere
   - Some features unavailable

Based on your needs, I'd recommend option 3 because..."

Every decision is a teaching moment.

During Scoping

Explain the trade-offs:

"We could build a custom CMS, but here's why we recommend an existing one:

Custom CMS:
- $30K to build
- Ongoing maintenance ($5K/year)
- You're dependent on us for changes

Existing CMS:
- $0 to build
- $2K/year subscription
- You can make changes yourself

The custom approach might feel more tailored, but the existing solution
is actually more powerful—and you own the capability."

Make the reasoning visible, not just the recommendation.

During Building

Show, don't hide:

Demo walkthrough:
"Here's what we built this week. Let me show you how it works:

This component handles authentication. We chose JWT tokens because...

Notice how this responds on mobile—we use responsive breakpoints at...

The data flows from here to here, which means if you ever need to...

Questions before we move on?"

Pull back the curtain. Clients can handle the complexity.

During Handoff

Transfer capability, not just assets:

Handoff session:
"Let's make sure you can maintain this without us.

Here's how to make common changes:
1. Adding a new page...
2. Updating content...
3. Modifying styles...

Here's when to call for help:
1. Database changes...
2. New integrations...
3. Performance issues...

Let's have you try making a change while I watch."

Handoff is practice, not presentation.

The Education Ladder

Different stakeholders need different education:

Decision Makers

  • Business impact focus
  • High-level trade-offs
  • ROI implications
  • Risk awareness
"This architecture choice means:
- 30% lower hosting costs
- Faster page loads (better conversions)
- Easier to scale when you grow
- Less vendor lock-in"

Implementers

  • Technical details
  • How-to knowledge
  • Maintenance procedures
  • Extension patterns
"Here's how the caching works:
- Request comes in
- Check KV store (line 23)
- If miss, query database (line 27)
- Cache result for 1 hour (line 31)

To adjust the cache time, change this constant..."

Users

  • Workflow integration
  • Feature usage
  • Best practices
  • Support resources
"To create a new campaign:
1. Click 'New Campaign' (top right)
2. Fill in these required fields...
3. The preview updates automatically...
4. Hit 'Publish' when ready

If something goes wrong, this status page shows system health."

Documentation as Education

Living Documentation

Documentation that teaches:

# Authentication System

## Why This Approach

We chose JWT tokens because:
- Stateless = scales easily
- Client can decode = fewer API calls
- Industry standard = good tooling

We did NOT choose sessions because:
- Would require session store
- Harder to scale across servers
- More server resources needed

## How It Works

[Diagram showing flow]

## Common Tasks

### Adding a new protected route
1. Import the auth middleware (line X)
2. Wrap your handler (example below)
3. Access user from context...

### Debugging authentication issues
1. Check token expiration...
2. Verify JWT secret matches...
3. Look for these error codes...

Decision Log

Why we chose what we chose:

# Decision Log

## 2025-01-15: Database Selection

**Decision**: Use D1 (Cloudflare SQLite)

**Alternatives Considered**:
- Postgres (Supabase): More powerful, but overkill for current needs
- DynamoDB: Good scaling, poor query flexibility
- Firebase: Lock-in concerns

**Rationale**:
- SQLite is familiar to team
- D1 is edge-deployed (fast everywhere)
- Cost-effective at current scale
- Easy migration path if needed

**Consequences**:
- Some complex queries need workarounds
- Need to handle eventual consistency
- Limited to Cloudflare ecosystem

Teaching Moments

When Things Go Wrong

Failures are teaching opportunities:

"The deployment failed because of X. Here's what happened:

1. We pushed code
2. Build process ran
3. Failed at step Y because...

Here's how we fixed it:
1. Identified the issue by...
2. Applied this fix...
3. Added this check to prevent recurrence...

This is now documented so your team can handle similar issues."

When Clients Ask Questions

Every question is an education opportunity:

Client: "Why is this so slow?"

WORKWAY: "Great question. Let me show you:

[Opens browser dev tools]

See this waterfall? Each bar is a request.
This large bar is the image—it's 2MB.
If we optimize images, this becomes fast.

There are tools that do this automatically.
Should I set that up and show you how it works?"

When Requirements Change

Change requests teach about trade-offs:

"You'd like to add feature X. Here's what that means:

Technical impact:
- Need to modify the data model
- Add new API endpoint
- Update the UI in three places

Timeline impact:
- 3 additional days
- Delays feature Y

Cost impact:
- +$X,XXX

Recommendation:
- If this is urgent, defer Y
- If not urgent, add to Phase 2
- Either way, let's document why for the team

What would you like to do?"

Building Client Capability

Self-Service Tools

Give clients tools to help themselves:

"We've created an admin dashboard where you can:
- View real-time analytics
- Update content without code
- Manage users
- Check system health

You won't need us for these tasks anymore."

Runbooks

Clear instructions for common scenarios:

# Runbook: Site is Down

## Check first
1. Go to status.cloudflare.com
2. Check if it's a Cloudflare issue

## If Cloudflare is fine
1. Go to dashboard → Deployments
2. Check last deployment status
3. If failed, click "Rollback"

## If still down
1. Check DNS propagation at dnschecker.org
2. Contact support with these details...

Training Sessions

Structured capability transfer:

Training Agenda:
1. System overview (30 min)
2. Daily operations (30 min)
3. Common issues and fixes (30 min)
4. Hands-on practice (30 min)
5. Q&A (30 min)

Recorded for future team members.

The Exit Criteria

A successful engagement ends when the client can:

  • Perform routine operations without assistance
  • Troubleshoot common issues
  • Make minor modifications
  • Know when to call for help
  • Train new team members

If the client still needs you for everything, you haven't finished.


Reflection

Before moving on:

  1. What knowledge do you typically not transfer to clients?
  2. How would your documentation change if written to teach?
  3. What would it mean for clients to truly not need you?

The goal is capability, not dependency.


Cross-Property References

Canon Reference: See Universal Utility for how education enables universal access—not just to features, but to understanding.

Canon Reference: Client education embodies Tool Complementarity—building human capability alongside systems.

Practice: The LMS itself (.learn) demonstrates these principles—teaching through progressive understanding, not just feature documentation.