What's in the Handover Package at the End of a Green Dolphin Engagement

The first time a buyer hires a consulting firm and the engagement ends with a Slack message saying "all done, let us know if you need anything" — and a private GitHub repo they can't access, and a deploy nobody documented — is the last time they hire a consulting firm without asking exactly what ships at handover.

This post is the inventory. Every artifact below is delivered at engagement acceptance on every Green Dolphin engagement — Starter through Custom. It is the boring, unglamorous side of fixed-bid consulting that makes the engagement actually survive after the architect leaves.

1. Source code — transferred to your GitHub

During the engagement, source code lives in the Green Dolphin GitHub organization. At delivery acceptance, the repos are transferred to your GitHub org — full IP transfer, full history, full branch protection rules. Your team becomes the owner.

Why transfer instead of clone-and-push: the original commit history is preserved (audit value), GitHub stars / forks / issues / PRs survive the move, CI integrations re-attach to the new org without rebuilding pipelines, and your IT / security team owns access control from day one.

2. Comprehensive README per repo

Every repository ships with a README.md that an engineer joining your team six months later can use without calling the original architect. Sections:

• Purpose — what business problem this repo solves
• Architecture summary — one paragraph + link to the design package
• Local setup — prerequisites, install, environment variables, exact commands
• Run — how to start the app or trigger the integration
• Test — how to run the unit + integration test suite
• Deploy — environment-by-environment deploy commands, including rollback
• Operate — link to the runbook (Section 6)
• Architecture decision records — ADR-style notes for non-obvious decisions

This is not a marketing README. It is the document your engineer reads at 11 PM on a Saturday during an incident.

3. Design package

The same design package the senior architect built during discovery + SOW, updated to match what actually shipped. Topology diagram (current state + target state), per-API design with full RAML 1.0 / OpenAPI 3.x specs, canonical data model with ERD + JSON schema, sequence diagrams for every business event, security + governance recommendations, deployment topology.

Stored as both editable source (Lucid / Miro / Mermaid / draw.io) and PDF export. Your team can keep editing it as the system evolves; auditors can read the PDF without an account.

4. ≥80% unit test coverage report

Coverage is a gate, not a target. Every shippable repo enforces ≥80% unit test coverage on application code in the CI pipeline. The coverage report (HTML + JSON) is attached to the handover package so your team has a baseline to maintain.

Tests are written in the framework native to the platform — Jest / Vitest for Node, pytest for Python, MUnit for MuleSoft, Apex tests for Salesforce, the appropriate native framework for Workato / Boomi / Snowflake. No skipped tests, no commented-out tests, no expect(true).toBe(true) filler.

5. Postman collection — every API endpoint

Every API endpoint built during the engagement has a corresponding Postman request in a collection that ships with the handover. Each request has:

• Example request body
• Expected response
• Auth configured (with environment variables for keys)
• Test assertions (status code, schema validation, key field checks)

The collection is used during post-deploy smoke testing in each environment, and then becomes the manual API testing tool your team uses for the lifetime of the system.

6. Runbook

A document your on-call engineer reads at 2 AM. For each integration flow:

• What this does — one paragraph
• Health check — how to confirm it's working
• Common failure modes — what to look for in the logs
• Recovery steps — how to restart, replay, or rollback
• Escalation — who to call after exhausting the runbook

The runbook is delivered as Markdown in the repo so it stays version-controlled alongside the code that it describes.

7. Deploy evidence per environment

Every environment in the engagement scope (typically Sandbox + UAT + Prod) gets deployed during the build phase, with evidence of successful deploy attached to the handover:

• Build artifact ID / commit SHA
• Deploy log / pipeline run URL
• Smoke-test results from the Postman collection
• Approval signature from your team

This evidence package is what your change-management board / SOX auditor / SOC 2 auditor asks for. We assemble it as the engagement runs, not retroactively.

8. Observability + monitoring dashboards

If your stack has an observability platform (Datadog / Splunk / Elastic / New Relic / Anypoint Monitoring / Boomi Observability), the handover includes pre-built dashboards for the new integrations: structured logs, error rate, latency p50 / p95 / p99, throughput, alert configuration.

If you don't have an observability platform, we don't build one as part of the integration engagement. That work belongs in a Managed Services agreement or a separate Architecture & Design scope.

9. Knowledge-transfer session

The final deliverable is not a document — it's a 2-hour recorded session between the senior architect and your team. Walk-through of every repo, demo of every flow, Q&A on architectural decisions, and a verbal handoff of any "watch out for this" knowledge that didn't make it into the runbook.

The recording is yours to keep. New hires watch it during onboarding.

What's NOT in the handover

To be explicit about scope boundaries — these are deliberately out-of-scope of a fixed-bid integration engagement:

• Production support after delivery acceptance — covered by a Managed Services add-on (10 hrs/week, $25K / 3-month minimum)
• CI/CD pipeline build-out — assumes you have a working CI/CD; building one is a separate engineering scope
• End-user training materials — we train your engineering team; we don't write user-facing docs for your business users
• Future enhancement roadmap — the Architecture & Design engagement covers strategic planning; the integration engagement ships what was scoped

Why this much rigor

Two reasons. First, Fortune 500 buyers expect this documentation density — anything less doesn't pass the procurement / security / change-management filter. Second, the documentation is what makes the system outlive the engagement. If we leave and the system becomes unmaintainable inside six months, the engagement failed regardless of whether the code worked on the day of delivery.

The full delivery model is at /process. The fixed-bid pricing structure is at /services/fixed-bid-integration. Sample design package artifacts are at /samples — including a representative target-state architecture, process API design, integration domain design, and developer onboarding guide, all drawn from real engagements (anonymized).

If you've been burned by a consulting handover that left your team unable to operate what was built, this inventory is what to ask for next time.