The Founder's Post-Launch Checklist

What your dev agency should hand off when the project is done. Complete ownership means complete control—code, access, documentation, deployment. Don't let critical assets stay with the vendor.

Why Handoff Matters

The agency's job isn't done when the site launches. It's done when you can run, maintain, and evolve the product without them. That means you need complete ownership of everything: code, infrastructure, credentials, documentation, deployment pipelines.

If the agency keeps critical assets (servers, admin passwords, deployment tools), you're dependent on them forever. Want to add a feature? You need them. Found a security issue? You're stuck waiting for their team. Need to switch to another agency? Nightmare negotiation.

Good agencies want you to succeed independently. They hand off everything because they want the work to be good and stable. Agencies that hold assets hostage are signaling that they don't trust their own work or they want recurring revenue through dependency. Both are red flags.

The Complete Handoff Checklist

Code & Repositories

What you need: Full source code for every component—frontend, backend, mobile apps, internal tools, infrastructure-as-code, everything.

  • GitHub/GitLab/Bitbucket access: Your account (not the agency's) has full read-write access. You can push, merge, manage. Not just "viewer" permissions.
  • Repository ownership: Your organization owns the repos, not theirs. Verify on GitHub before signing off.
  • Complete history: All commits, branches, tags. Nothing deleted or squashed to hide work.
  • Environment-specific configs: Dev, staging, production configs. (Scrubbed of secrets—see credentials below.)
  • Dependencies locked: package-lock.json, Gemfile.lock, requirements.txt, etc. You can rebuild the exact same environment.

Documentation

What you need: Documentation that lets your team (or a new agency) understand what was built and why.

  • Architecture overview: High-level diagram: how do frontend, backend, database, external services connect?
  • API documentation: Every endpoint, parameters, response formats. Even if it's auto-generated (good) instead of hand-written (acceptable).
  • Database schema: What tables exist, what do the relationships look like, what are the constraints?
  • Environment setup guide: "Here's how to run this locally for development." Step-by-step. Testable.
  • Deployment instructions: How do you get code from GitHub to production? What are the steps? What can go wrong?
  • Third-party integrations: What external services do you use? (Stripe, Twilio, etc.) How are they configured?
  • Known limitations/technical debt: "We did X as a shortcut. Here's why. Here's how to fix it later."
  • Decision log: Why did you choose this framework, this database, this architecture? Future you will want to know.

Access & Credentials

What you need: Every password, API key, and credential to run your product, stored securely so you can access it.

  • Server/hosting admin access: AWS, Vercel, Heroku, whatever you're using. You're the admin, not the agency. Change the password after handoff.
  • Database access: Direct access to production database, backups, migration tools. If you need to debug something, you can.
  • API keys & secrets: Stripe, Twilio, any external service. Stored in your password manager. Stored in your .env.production, not the agency's.
  • Admin panels & dashboards: Any internal tools you need to run the business. Payment dashboard, user admin panel, content CMS—all accessible to you.
  • DNS & domain registrar access: You own your domain. You control the DNS records. The agency has no "hold" on your domain.
  • Monitoring & logging access: Sentry, DataDog, New Relic, or whatever logging/monitoring they set up. You can see errors and performance data.

Security note: Store these in a password manager (1Password, Vault, etc.), never in shared docs. The agency shouldn't need access after handoff. If they ask to retain credentials "for support," that's a red flag.

Deployment & CI/CD Pipeline

What you need: Ability to deploy code changes without calling the agency.

  • Deployment scripts/automation: If you push to main, does it automatically deploy? How? You should understand the flow.
  • Rollback process: How do you revert to the previous version if something breaks? Documented. Tested.
  • Database migrations: If you change the schema, how do you apply migrations to production? Can you do it yourself?
  • Environment parity: Dev, staging, and production should be identical except for data. Staging should let you test before going live.
  • CI/CD configuration: GitHub Actions, CircleCI, whatever they used. You own it. You can modify it if you need to add tests or change deployment logic.

Monitoring, Alerting & Operations

What you need: Visibility into your system. What's running? Is it healthy? Are errors happening?

  • Error tracking: Sentry, Bugsnag, Rollbar, or similar. You see errors in real time. You know when something breaks.
  • Performance monitoring: Datadog, New Relic, or similar. You see if the app is slow or if you're running out of resources.
  • Uptime monitoring: Alerts when your site goes down. Ideally, your phone rings before customers notice.
  • Log access: You can check production logs if something goes wrong. Not just the agency.
  • Runbooks for common issues: "Site is slow. Here's how to diagnose." "Database is running out of space. Here's how to expand." Real operational knowledge, not just "call the agency."

Backups & Disaster Recovery

What you need: Ability to recover from data loss or catastrophic failure.

  • Automated backups: Database is backed up daily. Code is versioned in Git (immutable). You can't lose everything.
  • Backup verification: They've tested restoring from backups. Not just "we backup." Actually "we backup and we've confirmed we can restore."
  • Backup access: You can access backups directly, or at minimum you have clear procedures for restoring.
  • Disaster recovery plan: "If everything burns down, here's how we come back online." Documented. Not a mystery.
  • RTO & RPO targets: Recovery Time Objective (how fast can you come back) and Recovery Point Objective (how much data can you afford to lose) should be documented.

Maintenance & Support Agreement

What you need: Clarity on what happens after launch. Who supports it? For how long? At what cost?

  • Post-launch support period: 30-90 days of support while bugs emerge and you scale. Costs? Duration? Included or extra?
  • Bug fixes vs. enhancements: What's their responsibility to fix during this period? New features = your cost. Bugs = their responsibility.
  • Maintenance plan (optional): If you want them to handle ongoing ops (monitoring, updates, patch management), the rate and scope should be crystal clear.
  • Emergency support: Your site is down at 2am. Is there 24/7 emergency support? At what cost? Worth thinking through.
  • Knowledge transfer sessions: Your team needs to understand how to operate this. Are they doing training? How many sessions? Recorded?

Testing & Test Data

  • Automated test suite: Every critical path should have tests. You can run them before deploying. You can add more tests as you go.
  • Test data & fixtures: How do you populate test environment with realistic data? Documented and reproducible.
  • Staging environment: You can test changes before hitting production. Ideally with production-like data (scrubbed of PII).
  • Browser/device testing: Where was this tested? What browsers? What devices? Documented, so you know what to support.

Red Flags at Handoff

If your agency does any of these, push back hard or walk away:

  • "We'll keep the admin passwords. We'll manage access." No. You own your app. You own your passwords.
  • "The code is in our GitHub org under our license." Unacceptable. Move it to your account with your license.
  • "You'll need our team for ongoing support. We can do monthly retainers." Maybe, but not because they locked you in. Because they're actually valuable.
  • "Documentation is unnecessary. The code is self-documenting." No. You need to understand your own system.
  • "We'll handle monitoring. You don't need access." Controlling the visibility into your own system is red flag behavior.
  • "We haven't tested restoring from backups yet, but we will... eventually." Test now or don't claim you have backups.
  • "You'll need us to deploy any changes. Deployment is complex." Deployment should be a documented process any engineer can follow.

Before Signing Your Agency Contract

Make sure it explicitly covers handoff. What gets transferred? When? At what cost? Run your contract through our scanner to catch missing language.

Scan Your Contract

Tools for Post-Launch Confidence

Code Quality Analyzer

Audit the code you're receiving. Is it maintainable? Is it production-ready? Does it follow best practices?

Analyze Your Code →

Contract Scanner

Review your agency contract for handoff language. Are deliverables clear? Who owns what?

Scan Your Contract →

Tech Stack Scanner

Understand what you've been handed. What frameworks? What tools? What's cutting-edge vs. outdated?

Scan Your Stack →

Related Reading