The development phase is where everyone pays attention. Sprints get reviewed. Demos get scheduled. The Slack channel is active. You're watching every milestone.
Then the project launches, the agency wraps up, and the relationship quietly... ends.
Six months later, you need to update a payment integration. Or a library hits end-of-life and your app starts throwing errors. Or a new hire joins and nobody can explain how the deployment process works. You go back to the agency, and either they've moved on, the original developers are no longer on your account, or the quote to fix something small comes back at a number that makes no sense given the work involved.
This is where most outsourcing relationships actually break down — not during the build, but in the long silence after.
Why Post-Launch Is Where Trust Gets Made or Broken
Agencies are incentivized to be excellent during delivery. That's when you're watching, and that's when the invoice gets paid. Post-launch support is different. It's often under-scoped, under-priced, and deprioritized against the agency's newer, more lucrative projects.
That's not an indictment of every agency — it's just how most engagement models work. The problem is that from your side, post-launch is when you need them most. Bugs show up in production that never surfaced during testing. Users do things users do. Infrastructure needs tuning. Features get requested that require understanding decisions made six months ago.
If the handover was clean and the SLA is clear, this phase is manageable. If neither exists, you're in trouble.
The Three Things That Must Exist at Handover
Before your agency closes out a project, there are three deliverables that have nothing to do with features — and they matter more than the feature list over the long run.
Documentation. Not a README that says "this is a Laravel app." Real documentation: what the system does, how the major components fit together, what third-party services it connects to and why, what assumptions were made during development that a new developer needs to know. If someone joins your team a year from now and the original agency is unreachable, can they get up to speed without a panic? That's the bar.
A runbook. A runbook is the operational document that tells anyone — developer, ops person, or you — how to keep the system running. How do you deploy? How do you roll back if something goes wrong? What do the alerts mean? What do you do if the database is slow? This document is boring to write and invaluable to have. Insist on it.
Bus factor reduction. The "bus factor" is the number of people who could be hit by a bus before the project becomes unmaintainable. If the answer is one — and that one person works for the agency, not you — you have a serious dependency problem. Handover means knowledge transfer, not just file transfer. Schedule sessions where the team walks through the codebase with your developers or technical lead. Record them if needed.
What a Good Maintenance SLA Actually Looks Like
Service Level Agreements for maintenance are often vague to the point of being useless. "We'll respond within 24 hours" tells you almost nothing about what kind of response, what kind of issue, or whether that response leads to a fix.
A functional maintenance SLA should define severity tiers:
- Critical (P1): The application is down or a core function is broken for all users. Response within 1–2 hours, resolution target within 4–8 hours.
- High (P2): A major feature is impaired but the application is still running. Response within 4 hours, resolution within 24–48 hours.
- Medium (P3): A non-critical bug affecting some users. Response within 1 business day, resolution within 5 business days.
- Low (P4): Minor issues, cosmetic bugs, UX improvements. Batched into scheduled maintenance cycles.
It should also clarify: what's included in the monthly retainer versus what gets billed separately? New feature development is almost always separate. Bug fixes from code the agency wrote? That should be covered. Infrastructure failures? Depends on who manages the infrastructure. Get these boundaries in writing.
Knowledge Transfer: Staying Out of the Hostage Situation
The most uncomfortable truth about software development is this: if only one team understands your codebase, they own you.
This dynamic is rarely intentional. It's the natural result of a single team building something over months without sharing what they know along the way. By the time they leave, the knowledge is gone with them.
Protecting yourself means actively investing in knowledge transfer before the project ends:
Code ownership from day one. Your code should live in a repository under your account, not the agency's. This is non-negotiable. At any point, you should be able to grant access to a new developer without the agency's permission.
Architecture review sessions. Before the agency wraps, schedule at least two or three sessions where they walk your internal team (or a trusted technical advisor) through the system. Not a demo — an explanation of why things were built the way they were.
Documented decisions. Architectural Decision Records (ADRs) are simple documents that capture major choices: "We chose PostgreSQL over MySQL because..." or "We used a microservices pattern here because..." They don't take long to write and they prevent a new team from undoing months of considered thinking.
Gradual transition. If budget allows, don't end the agency relationship abruptly. Run a transition period where your new maintainer (whether in-house or a new agency) works alongside the original team for 4–6 weeks. Questions get answered in real time, context transfers naturally.
Questions to Ask Before You Sign
Most clients evaluate agencies on delivery capabilities — portfolio, process, technology stack, price. Fewer think to ask about what happens after launch. These questions should be part of every evaluation:
"What does your standard handover package include?" If they look confused or give a vague answer, that's the answer.
"Can you walk me through a maintenance SLA you've used with another client?" Asking for a real example separates agencies that have done this from agencies that will promise anything to close the deal.
"How do you handle a situation where the original developer on my project is no longer available?" Good agencies have processes for knowledge continuity. Bad ones will tell you that won't happen.
"What happens if I want to move to a different agency after you've built the product?" The answer should be: "We make that easy." Code in your repo, documentation in your hands, infrastructure in your accounts. Anything less is a red flag.
"Who manages the hosting and infrastructure accounts?" Everything should be in your name. Your cloud credentials, your domain, your email delivery service. You are the owner of your own product.
The Long Game
A software product isn't done when it launches. It's done when it's retired — and that's typically years away. The agency you hire to build version one is setting the foundation for every version that follows.
Post-launch maintenance shouldn't feel like a mystery or a hostage negotiation. When the handover is thorough, the documentation is real, and the SLA is specific, it becomes what it's supposed to be: routine upkeep on something that works.
The agencies that do this well aren't doing you a favor. They're doing their job. Hold the ones you evaluate to that standard — before you sign, not after you've already launched.
