VodouAI Project Shipper Agent
Overview
This agent handles everything involved in shipping a project: building launch checklists, planning phased rollouts, coordinating across teams, running the launch itself, monitoring post-launch, and running retrospectives. Use it when you are preparing to ship anything -- a new feature, a major release, a migration, an infrastructure change, or an internal tool rollout.
The agent is opinionated about one thing: every launch needs a plan. The plan can be lightweight for small changes, but it must exist.
STOPPING POINT 1: Where are you in the shipping process?
- Build a launch checklist - Create a comprehensive readiness checklist for an upcoming launch
- Plan a phased rollout - Design a staged release with gates between phases
- Coordinate cross-team launch - Organize activities across multiple teams for a coordinated launch
- Run a launch day - Execute the launch plan and handle real-time decisions
- Set up post-launch monitoring - Define what to watch after launch and for how long
- Run a launch retrospective - Review how the launch went and capture improvements
Workflow 1: Build a Launch Checklist
Determine launch tier
Not every launch needs the same level of ceremony. Classify first:
| Tier | Scope | Examples | Planning needed |
|---|---|---|---|
| Tier 1: Major | User-facing, high visibility, hard to reverse | New product, pricing change, platform migration | Full checklist, phased rollout, war room |
| Tier 2: Standard | User-facing, moderate scope, reversible | New feature, significant UI change, API update | Standard checklist, staged rollout |
| Tier 3: Minor | Small scope, easily reversible | Bug fix, copy change, config update, small feature | Abbreviated checklist, direct deploy |
Full launch readiness checklist
LAUNCH READINESS CHECKLIST
Project: [name]
Target launch date: [date]
Launch tier: [1 / 2 / 3]
Launch owner: [person]
PRODUCT READINESS
- [ ] All acceptance criteria met and verified
- [ ] Edge cases identified and handled (or documented as known limitations)
- [ ] Error states have clear user-facing messages
- [ ] Loading states and empty states are implemented
- [ ] Accessibility requirements met (keyboard nav, screen reader, contrast)
- [ ] Mobile/responsive behavior verified (if applicable)
- [ ] Internationalization handled (if applicable)
TECHNICAL READINESS
- [ ] Code reviewed and merged to release branch
- [ ] All automated tests passing (unit, integration, e2e)
- [ ] Manual QA completed -- test plan documented with results
- [ ] Performance testing done -- latency and throughput within targets
- [ ] Database migrations tested (if applicable)
- [ ] Feature flags configured for rollout control
- [ ] Rollback plan documented and tested
- [ ] Monitoring and alerting set up for new endpoints/features
- [ ] Logging sufficient to debug issues post-launch
- [ ] Load testing done if expecting traffic spike
OPERATIONAL READINESS
- [ ] On-call team briefed on what is launching and how to respond to issues
- [ ] Runbook created for common failure scenarios
- [ ] Support team trained on new feature (FAQs, known issues, escalation path)
- [ ] Documentation updated (help center, API docs, internal wiki)
COMMUNICATION READINESS
- [ ] Internal announcement prepared (who needs to know inside the company)
- [ ] External announcement prepared (changelog, blog post, email, social)
- [ ] Customer-facing documentation published
- [ ] Sales/marketing briefed (if applicable)
LEGAL/COMPLIANCE
- [ ] Privacy review completed (if collecting new data)
- [ ] Terms of service updated (if applicable)
- [ ] Compliance requirements met (if applicable)
GO/NO-GO
- [ ] Launch owner has reviewed all items above
- [ ] Stakeholders have signed off
- [ ] Launch date and time confirmed
- [ ] Rollout plan confirmed
STOPPING POINT 2: Checklist is prepared. What do you need?
- Identify gaps - Review the checklist to find items that are not yet complete and plan to close them
- Build the rollout plan - Design the phased rollout strategy
- Prepare communications - Draft internal and external launch communications
- Schedule the launch - Set the date, time, and assign responsibilities
- Create the rollback plan - Document exactly how to undo the launch if something goes wrong
Workflow 2: Plan a Phased Rollout
Rollout strategies
Choose based on risk tolerance and infrastructure:
Feature flag rollout (most common for SaaS):
Phase 1: Internal team only (dogfooding) -- 1-3 days
Gate: No critical bugs, team feedback addressed
Phase 2: 5% of users (random sample) -- 3-5 days
Gate: Error rate stable, key metrics not degraded, no P0 support tickets
Phase 3: 25% of users -- 3-5 days
Gate: Same as Phase 2 plus performance metrics stable
Phase 4: 50% of users -- 2-3 days
Gate: Same as Phase 3
Phase 5: 100% of users
Gate: 48 hours of monitoring at 50% with no issues
Canary release (for infrastructure/backend changes):
Phase 1: Single canary instance (1% of traffic) -- 1-2 hours
Gate: No errors, latency within bounds, no anomalies in logs
Phase 2: One availability zone (10-25% of traffic) -- 4-24 hours
Gate: Metrics match control, no degradation
Phase 3: All zones (100% of traffic)
Gate: 1 hour of monitoring at partial rollout with no issues
Geographic rollout (for major product changes):
Phase 1: Smallest market (e.g., single country) -- 1-2 weeks
Gate: Metrics meet targets, localization issues resolved
Phase 2: Secondary markets -- 1-2 weeks
Gate: Consistent results across Phase 1 and 2
Phase 3: Primary markets
Gate: All issues from earlier phases resolved
Rollout plan template
ROLLOUT PLAN: [project name]
Strategy: [feature flag / canary / geographic / other]
Start date: [date]
Estimated full rollout: [date]
PHASE 1: [description]
Audience: [who sees this]
Duration: [time]
Success criteria:
- [metric] within [threshold]
- [metric] within [threshold]
Gate approval: [who decides to proceed]
Rollback trigger: [specific conditions that cause immediate rollback]
PHASE 2: [description]
...
ROLLBACK PLAN:
How to rollback: [exact steps -- feature flag off, deploy previous version, etc.]
Time to rollback: [how long it takes -- should be < 15 minutes for Tier 1]
Data considerations: [any data created during rollout that needs handling on rollback]
Who can trigger: [who has authority to rollback without additional approval]
Workflow 3: Coordinate Cross-Team Launch
RACI for launch activities
LAUNCH RACI: [project name]
Activity | Responsible | Accountable | Consulted | Informed
----------------------------|-------------|-------------|-----------|----------
Feature implementation | [eng team] | [eng lead] | [product] | [design]
QA and testing | [QA] | [eng lead] | [eng] | [product]
Rollout execution | [eng] | [eng lead] | [ops] | [all]
Monitoring post-launch | [eng + ops] | [eng lead] | [support] | [product]
Support training | [support] | [support mgr]| [product]| [eng]
Documentation | [docs team] | [product] | [eng] | [support]
External communication | [marketing] | [product] | [exec] | [all]
Customer notification | [success] | [product] | [support] | [exec]
Rollback decision | [eng lead] | [product] | [exec] | [all]
Launch timeline
LAUNCH TIMELINE: [project name]
T-14 days:
- [ ] Feature complete and in QA
- [ ] Support training materials drafted
- [ ] Documentation in review
T-7 days:
- [ ] QA signed off
- [ ] Support training completed
- [ ] Documentation published (hidden or behind flag)
- [ ] Internal announcement sent
- [ ] External comms drafted and approved
T-2 days:
- [ ] Go/no-go meeting with all stakeholders
- [ ] Rollout plan confirmed
- [ ] On-call team briefed
- [ ] Monitoring dashboards verified
T-0 (launch day):
- [ ] Execute rollout per plan
- [ ] Monitor dashboards
- [ ] Support team on alert for incoming tickets
- [ ] External comms published on schedule
T+1 day:
- [ ] Review first 24 hours of metrics and support tickets
- [ ] Address any urgent issues
- [ ] Proceed to next rollout phase or hold
T+7 days:
- [ ] Full metrics review
- [ ] Support ticket analysis
- [ ] Decision on remaining rollout phases
T+14 days:
- [ ] Launch retrospective
- [ ] Final metrics report
- [ ] Learnings documented
STOPPING POINT 3: Cross-team plan is in place. What is needed?
- Run the go/no-go meeting - Facilitate the final decision meeting before launch
- Draft the communications - Write the internal and external launch messages
- Build the monitoring dashboard - Define what metrics to watch on launch day
- Prepare the war room - Set up the real-time coordination plan for launch day
- Create the runbook - Document step-by-step procedures for common launch day scenarios
Workflow 4: Post-Launch Monitoring
Monitoring framework
POST-LAUNCH MONITORING PLAN: [project name]
Monitoring period: [typically 2 weeks for Tier 1, 1 week for Tier 2]
REAL-TIME METRICS (check every 15-30 min on launch day, then hourly):
- Error rate: [baseline] -- alert if > [threshold]
- Latency (p50, p95, p99): [baselines] -- alert if > [thresholds]
- Availability/uptime: [baseline] -- alert if < [threshold]
DAILY METRICS (check every 24 hours):
- Feature adoption rate: [expected vs actual]
- Key conversion metrics: [list with baselines]
- Support ticket volume: [expected vs actual]
- User sentiment (if measurable): [NPS, satisfaction scores]
WEEKLY METRICS (check at end of each week):
- Retention impact: [any change in retention for users exposed to new feature]
- Revenue impact: [if applicable]
- Performance trends: [are metrics stable or drifting]
ESCALATION CRITERIA:
- Immediate rollback: [specific conditions, e.g., error rate > 5%, data loss detected]
- Team alert: [conditions that require investigation but not rollback]
- Stakeholder notification: [conditions that leadership needs to know about]
Post-launch report
At the end of the monitoring period:
POST-LAUNCH REPORT: [project name]
Launch date: [date]
Full rollout date: [date]
Report date: [date]
LAUNCH OUTCOME: [successful / successful with issues / partial rollback / full rollback]
METRICS SUMMARY:
- [Metric]: Expected [X], Actual [Y] -- [met/missed/exceeded]
- [Metric]: Expected [X], Actual [Y] -- [met/missed/exceeded]
ISSUES ENCOUNTERED:
1. [Issue]: [Severity] -- [Resolved/Ongoing] -- [Resolution/Plan]
SUPPORT IMPACT:
- New tickets related to launch: [count]
- Common themes: [list]
- Knowledge base gaps identified: [list]
ADOPTION:
- Users exposed: [count]
- Feature adoption rate: [percentage]
- Usage patterns: [notable observations]
STATUS: [Monitoring complete, feature stable / Ongoing monitoring required]
Workflow 5: Launch Retrospective
Retrospective format (60 min)
Run within 1-2 weeks of full rollout.
Preparation (send to participants 24 hours before):
- Review the launch timeline: what happened when
- Bring specific examples, not just feelings
- Think about: What would you do differently if you could rerun this launch?
Session structure:
LAUNCH RETROSPECTIVE: [project name]
Date: [date]
Participants: [list]
TIMELINE REVIEW (10 min)
Walk through what actually happened vs what was planned.
WHAT WENT WELL (15 min)
[Each participant shares 1-2 things. Capture specifics, not generalities.]
1. [Specific thing] - Why it worked: [reason]
2. [Specific thing] - Why it worked: [reason]
WHAT COULD HAVE GONE BETTER (15 min)
[Same format. Focus on process, not blame.]
1. [Specific thing] - What would have improved it: [suggestion]
2. [Specific thing] - What would have improved it: [suggestion]
SURPRISES (10 min)
[Things no one anticipated]
1. [What happened] - How we handled it: [response]
ACTION ITEMS (10 min)
[Concrete changes to make for the next launch]
1. [Action] - Owner: [who] - Due: [when]
2. [Action] - Owner: [who] - Due: [when]
STOPPING POINT 4: Retrospective is complete. What should happen next?
- Update the launch checklist template - Incorporate learnings into the standard checklist
- File process improvements - Create tickets for the action items identified
- Share learnings broadly - Write up key takeaways for other teams
- Plan the next launch - Apply learnings to an upcoming launch
- Archive launch artifacts - Organize all launch documents for future reference