The agency delivered. Then it stopped answering. That part you were half expecting. What you weren't expecting is the conversation three weeks later, when your own developer has been inside the code long enough to answer every feature request the same way: we have to fix this part first.
A development agency went dark and left you a product that works — as long as nothing about it changes.
This piece assumes you can still log into everything. Access is a separate problem with a separate answer. This one is about what you do next, once you know what you're holding.
What a development agency that went dark actually leaves behind
Not broken code, usually. The product runs. People are using it. Money is moving through it.
What's gone is the reasoning. Why the orders table is shaped that way. What the workaround in the checkout flow is compensating for. Which parts were built properly and which were built to make the launch date and never revisited. That knowledge lived in one or two heads and in a WhatsApp thread, and it left when they did.
So your team starts finding things. A booking system that just checks a slot and writes a reservation, with no real locking behind it — fine at ten members a day, and then two people get assigned the same equipment slot the moment real traffic hits. A billing system and an access system that were never actually wired to each other, so a failed payment doesn't reliably shut anything off, and someone on the team ends up fixing it by hand in a spreadsheet. A pricing setup built assuming there would only ever be one location, so a change meant for one branch quietly overwrites pricing everywhere. None of it was a mistake at the time. All of it is now standing between you and the next three features on your roadmap.
The product isn't broken. It's finished — in the sense that it can't go anywhere new without part of it being rebuilt first.
That's the real shape of what you're facing, and it's worth naming precisely, because it's the reason the obvious answers don't fit. You don't have one job. You have two, running at the same time: repair the parts that can't hold what's coming, and keep shipping what customers are already asking for.
Almost every founder in this position reaches for one of three options. It's worth being specific about why each one struggles against this particular shape.
Hire someone full-time
The instinct behind this is correct. You want capacity that stays, learns the system, and stops the bleeding permanently.
The problem is arithmetic. One hire is one skill set, and the two jobs in front of you aren't the same job. Redoing a data model that can't handle the volume you're now seeing is slow, senior, mostly invisible work. Shipping the features your customers are waiting on is a different rhythm entirely — and often a different specialist, if one of those features is mobile and the person you hired is a backend engineer.
One person does those sequentially, not simultaneously. So for the first few months you're choosing: ship nothing, or fix nothing.
And that's the picture after they start. Before that comes the search, the notice period, and the ramp-up on a codebase with no documentation and nobody to ask.
Bring in another agency
This option at least matches the size of the problem. It struggles somewhere else: an agency sells projects, and a project needs a scope.
To quote you, they have to know what's wrong. To know what's wrong, they have to read through work nobody documented. Most will propose a paid discovery phase first, which is a reasonable thing for them to ask for — but it means you're spending money to find out how bad it is before a single thing gets fixed.
What comes back after that is a fixed price quoted against a codebase that's still only partly mapped. That number is either padded to cover the unknowns, or it isn't and the unknowns turn into change requests three months in.
Then the project ends, the team rolls off, and your roadmap keeps going without them. You are exactly where you started, at a different address.
Post it on a freelance marketplace
Fastest and cheapest to arrange, and that matters when the backlog is already late.
But almost nobody on a part-time arrangement will take ownership of untangling another team's architecture. It's the least rewarding work in software — high judgment, slow, and nothing visible to show at the end of it. What you tend to get instead is a patch around the problem rather than a fix to it. Which is another undocumented decision, made by someone who won't be here next quarter to explain it.
What the problem actually asks for
Look at the two jobs again and the requirement is fairly clear. You need work that changes shape as it goes: senior backend attention on the data model now, frontend when that's stable, a mobile specialist when the release comes around, without hiring three people or re-scoping a full project every time the need shifts.
That's the fourth option, and it's the one most founders don't know exists as a defined thing. A Continuous Development Contract is a monthly subscription that gives your business its own developer: each task has a defined scope, its own due date, and the specialist that task needs. When the work moves from repair to roadmap, the person doing it changes. The subscription doesn't restart, and the Project Lead stays the same. If you need repair and roadmap moving at the same time, you add a second developer.
It also treats the missing-documentation problem as an engineering problem instead of a staffing one. Decisions get written down, project state stays visible, and continuity stops depending on any single person's memory — which is a large part of why we built our own client portal the way we did.
The decision you're actually making
A development agency going dark is not the problem you're actually solving. It's the event that exposed one: you were resourcing continuous product work as though it were a one-time build, and it was always going to run out.
The three familiar options are all shaped for other situations. Full-time hiring is right when you have steady, predictable work for one skill set. Project agencies are right when the scope is known and finite. Freelancers are right for contained, well-defined tasks.
None of those describes a live product carrying inherited technical debt and a roadmap that doesn't stop. That situation has its own answer, and it's worth knowing the answer exists before you commit six months to one of the other three.
