Your developer stopped answering and the software is half-built. Here is what to secure first, what you actually own, and how to decide whether to finish, fix, or rebuild.
Software Development Solutions
Looking for a software development partner?
We build domain-led systems tailored to your industry and workflow. 12 years. 2,100+ engagements.
The replies got slower first. Then the demo you were promised slipped, and then it slipped again. Then one morning your messages went unread, the invoices stopped, and you realized the person building your software was not coming back.
If that is where you are right now, take a breath. Half-built software is one of the most common situations in custom development, and it is almost always recoverable. What decides how painful the recovery gets is not the code itself. It is what you do in the next few steps, and the order you do them in.
The very first move has nothing to do with finding a new developer. It is making sure you still control everything the old one touched, because some of it may be in their name, not yours.
Secure These First
5 Things to Get Under Your Control Before Anyone Touches the Code
1
Hardest to Replace
The Code Itself
Find out where the code lives, usually an online code repository, and whose account holds it. If it sits in the developer's personal account, ask in writing for it to be transferred to an account your business owns. If the only copy is on their laptop, getting a full copy is the single most urgent thing on this list.
2
Your Customers Live Here
The Database and Its Backups
If the software is already in use, the database holds your customers, orders, and records. Make sure you can log into wherever it is stored, and take a fresh backup you keep yourself. Code can be rewritten if it has to be. Lost customer data usually cannot.
3
Easy to Lose Quietly
Your Domain Name
Check who the domain is registered to and which email address controls it. If it is registered in the developer's name, or tied to their email, move it to your own account. A domain that quietly expires, or sits in someone else's control, can take your whole site and email offline.
4
Where It Runs
Hosting and Server Accounts
Whatever the software runs on, a hosting company or a cloud account, needs to be in your business's name with you as an owner. Add yourself with full access, then remove the developer's access once you have copies of everything. Keep a record of what you changed and when.
5
The Hidden Connections
Every Outside Service It Uses
Payment providers, email senders, maps, app store listings, and every other service the software connects to. Each has its own account and its own access keys. List them all, make sure each account belongs to your business, and replace any keys the developer set up once a new team is in place.
Access Before Opinions
Every decision that comes later, finish it, fix it, or rebuild it, depends on having all 5 of these under your control. Nobody can judge software they cannot see, and nobody can safely change software that someone else can still switch off.
If the developer is still reachable, even reluctantly, this is the moment to ask for everything politely and in writing. People who walk away from a project are often embarrassed rather than hostile, and a calm, specific request gets far more back than an angry one.
The "Just Finish It" Trap
Once access is sorted, the natural instinct is to find someone new and tell them to just finish it. You have already put a lot into the work. Surely the remaining part is small, and a fresh pair of hands can wrap it up.
That instinct is the most common reason software rescues go badly. Why? Because nobody yet knows what "the remaining part" actually is. The last developer's status updates described what they meant to build, not necessarily what exists, how well it works, or what shortcuts sit underneath.
A new developer who is told to "just finish it" usually does 1 of 2 things. They pick up where the last one stopped and inherit every hidden problem, or they quietly start rewriting large parts because the code is unfamiliar. Either way, new work starts before anyone has checked what the starting point really is.
The better first question is not "who can finish this?" It is "what have we actually got?" That question has a clear answer, and getting it is faster and calmer than it sounds.
What to Say to the Next Developer
Instead of "please finish this," ask "please tell us what we have, what state it is in, and what it would take to get it to a finished product we can rely on." A developer who starts with that answer is protecting you. One who starts coding straight away is guessing.
What You Actually Own Right Now
Before anyone decides what to do with the software, it helps to know what is legally and practically yours. Most business owners assume that paying for code means owning it. In the US, that is not automatically true when the work was done by a contractor or an agency rather than an employee.
Here is why. Under US copyright law, a piece of work only counts as "made for hire", and therefore belongs to the business that ordered it, if it was made by an employee in their job, or if it falls into a short list of specific categories and both sides signed a written agreement saying so. Software is not one of those categories.
That means code written by an outside contractor generally belongs to the contractor until they transfer it. And the law is specific about how that transfer works: "A transfer of copyright ownership, other than by operation of law, is not valid unless an instrument of conveyance, or a note or memorandum of the transfer, is in writing and signed by the owner of the rights conveyed."
So what should you look for? Check your contract for a clause that assigns the rights in the work to your business, sometimes called an intellectual property assignment. If you find one signed by the developer, you are likely in a strong position. If you cannot find one, a short written assignment signed by the developer now can often settle it.
This is general information about US law, not legal advice, and other countries have their own rules. If the software is important to your business, have a lawyer read your contract before you assume either way. It is a small step that removes a large risk.
Ownership also has a practical side that no contract covers. A lot of what you paid for lived in the developer's head: how to set the software up from scratch, why certain decisions were made, which parts were temporary, and what still needed fixing. Some of that can be recovered from the code and the project history. Some of it will have to be rediscovered, which is exactly why the next step matters.
Half-Built Is Not the Same as Broken
"Half-built" covers a very wide range. Some unfinished software is well made and simply incomplete. Some works in a demo and falls apart under real use. The right move depends entirely on which kind you have, and you cannot tell by looking at the screens.
4 Kinds of Unfinished Software
What You Might Be Holding, and What Each One Needs Next
All 4 can look identical in a quick demo. The difference only shows up when someone reads the code and tries to run it from scratch.
Kind 1
Solid but Unfinished
Clean, readable code with a sensible structure and some tests. Features are missing, but what exists was built properly and runs from a fresh setup.
Next step: finish it, starting with the missing features customers need most.
Kind 2
Working but Fragile
It runs, and parts are already in use. But there are no tests, lots of quick fixes, and every change seems to break something else nearby.
Next step: stabilize the parts in use first, then keep building on firmer ground.
Kind 3
A Demo on Shortcuts
The screens look finished, but data is hard-coded, logins are not real, and security was left for later. It shows the idea well and holds very little weight.
Next step: keep the design and the thinking, rebuild the core properly underneath.
Kind 4
Built on the Wrong Foundation
The technology does not fit the job, the structure cannot grow, or there are security problems baked in deep. Adding features only adds weight to a base that will not hold.
Next step: rebuild, reusing the designs, data, and requirements you already have.
Nothing You Paid For Is Wasted
Even in kind 4, the designs, the data, the decisions, and the lessons about what your customers need all carry forward. A rebuild with that head start is a very different project from starting at zero.
Which kind do you have? You will not know from the demo, and you should be wary of anyone who claims to know from the demo alone. Kinds 1 and 3 can look almost identical on a screen. The difference is in whether the software can be set up from scratch, how it handles real data, and what happens when someone changes it.
The honest answer is also sometimes mixed. One part of the software may be solid while another is a shortcut. That is normal, and it is fine, because the plan can treat each part on its own merits instead of forcing a single decision on the whole thing.
If your half-built software came together quickly with AI coding tools, the same 4 kinds apply. AI tools are a genuinely good way to build fast. They also make it easy to reach kind 3, a convincing demo, without the foundations a product needs, which is covered in why 99% of AI-built products will fail, even though anyone can build them now.
What a Proper Takeover Looks Like From the Inside
A takeover done well is calm, methodical, and a little boring. It does not start with new features. It starts with understanding, because every hour spent understanding the software saves several spent undoing guesses later.
Here is what the work actually involves once a new team steps in.
Getting It Running Somewhere You Control
The first real test is setting the software up from scratch, on accounts your business owns. If that works, you know the code is complete. If it does not, you learn exactly what is missing, which is far better to discover now than the day something breaks in front of customers.
Reading the Code Before Changing It
An independent review looks at how the software is structured, how secure it is, whether it has tests, and whether the building blocks it depends on are current. The result is a plain-English report on what is solid, what is fragile, and what is missing, before anyone writes a new line.
Writing Down What Was Never Written
Most half-built projects have little documentation. A good takeover rebuilds it as it goes: how to set the software up, how the main parts fit together, and why key decisions were made. That record is what stops you from ever being this dependent on a single person again.
Finishing in Small, Verified Pieces
Once the starting point is clear, the work moves in small pieces you can see working, each one tested and shown to you before the next begins. You stop relying on status updates and start seeing real progress you can click through yourself.
The review in the second step is the one to insist on. On our side, it is a standalone service, an independent assessment of your existing systems covering code quality, security, and what it would take to grow. You get a clear picture whether or not the same team goes on to do the build.
How long does all of this take? It depends on the size of the software and how much was left undocumented, so any honest answer comes after the review, not before it. What you can expect is that the review gives you a clear, specific plan instead of a guess.
What a New Team Cannot Rescue
A good takeover recovers most situations, but not everything. So what can even a strong team not fix? Knowing those limits up front keeps expectations realistic, and it helps you decide what to finish and what to let go.
It Cannot Recover Code Nobody Can Find
If the only copy of the code lived on the developer's own machine and they will not share it, it is gone. What remains useful is everything else: the working screens, the designs, the data, and your knowledge of what the software was meant to do. A rebuild from those is still far ahead of starting cold.
It Cannot Read Decisions That Were Never Written Down
Some choices in the code will have had a reason only the old developer knew. A new team can usually work out the reason, and sometimes cannot. Where it cannot, the decision gets made again deliberately, which often turns out better than the original.
It Cannot Keep Every Promised Feature Exactly as Planned
The original plan was written before anyone knew what the code would really look like. Once the review is done, some features may be worth trimming, reordering, or simplifying. That is not a failure. It is the plan catching up with reality.
It Cannot Skip the Review and Still Be Safe
When a deadline is pressing, skipping the review feels like saving time. In practice it moves the discovery of problems from the start, where they are quick to handle, to the middle of the build, where they are slow and disruptive. The review is the time-saver.
It Cannot Settle a Dispute With the Old Developer
Questions about who owns the code, what was delivered, and what was owed belong with a lawyer, not a development team. A new team can document what exists and what state it is in, which helps that conversation, but it cannot decide it.
Notice that none of these limits leave you stuck. Each one has a clear way forward, and most of them get easier once someone who has done this before is looking at the actual code rather than the status updates.
How to Take Back Control, Step by Step
Everything above comes together in a simple order. Each step makes the next one safer, so it pays to follow the sequence even when it is tempting to skip ahead.
The Three Stages
From a Stalled Project to Software You Fully Control
STAGE
1
Secure
Get every account and every copy under your control.
STAGE
2
Assess
Find out which kind of unfinished software you have.
STAGE
3
Restart
Finish, fix, or rebuild with a written plan.
The Real Order
Stage 1 protects you. Stage 2 tells you the truth. Stage 3 only goes well because the first 2 came before it.
Inside those 3 stages sit 5 concrete steps. Here is what each one involves.
Lock Down Every Account
Work through the 5 items at the top of this page: the code, the database, the domain, the hosting, and every outside service. Make your business the owner of each, add a second trusted person as a backup owner, and remove the old developer's access once you have copies of everything.
Collect Everything That Exists
Gather the code, database backups, designs, requirement documents, emails, chat history, and any invoices describing what was delivered. Put them in 1 folder your business owns. That bundle becomes the starting brief for whoever looks at the software next.
Get an Independent Review Before Anyone Writes Code
Ask for a written review that answers 3 questions: can the software be set up from scratch, which of the 4 kinds is each part, and what would it take to reach a finished product you can rely on. Make sure the answer comes in plain English you can follow.
Decide: Finish, Fix, or Rebuild
With the review in hand, decide part by part rather than all at once. Solid parts get finished, fragile parts get stabilized, and parts built on shortcuts get rebuilt properly. Many rescues end up as a mix of all 3, and that is usually the smartest outcome.
Restart With a Written Plan and Small Releases
Agree on a written plan that lists what gets built, in what order, and how you will see each piece working. Then move in small releases you can test yourself. Seeing working software regularly is the best early warning you will ever have if something starts to drift again.
Which step do people most often rush? The third. When you have already lost time, a review feels like more delay. It is the opposite: it is the step that turns a stressful guess into a plan you can actually hold someone to.
How to Make Sure It Never Happens Again
Once the software is back under control, a few simple habits make sure you are never this exposed again, whoever you work with next. None of them require you to become technical. They are about ownership, visibility, and paperwork.
Start with the contract. Whoever builds your software next, make sure the agreement includes a clear written assignment of the rights in the work to your business, signed by them. It is a standard clause, and a trustworthy developer or agency will not hesitate to sign it.
Next, own the accounts from day one. The code repository, the hosting, the domain, and every outside service should be set up in your business's name, with the developer invited in rather than the other way round. If the relationship ends, you simply remove their access. Nothing needs to be handed back because nothing ever left.
Then make documentation part of what you pay for. How to set the software up, how the main parts connect, and why key decisions were made should be delivered alongside the features, not promised for later. Documentation that arrives with the work is documentation that actually exists.
Finally, ask to see working software regularly, not just status updates. A short demo of something you can click through tells you more than any progress report. If the demos start slipping, you will notice early, while there is still time to ask why.
The Question That Protects You Next Time
Before you sign with any developer or agency, ask: "If we stopped working together tomorrow, what would we have, and what would we need to get back from you?" The right answer is "you would have everything already, in your own accounts." Anything else tells you where the risk sits.
If you are choosing a new team right now, how to choose a software development company walks through the red flags and the questions that separate a reliable partner from the next disappearing act.
Frequently Asked Questions
Who owns the code if my developer walked away?
In the US, code written by your own employee as part of their job generally belongs to your business. Code written by a contractor or agency generally belongs to them unless there is a signed written transfer of the rights to you. Check your contract for an intellectual property assignment, and have a lawyer confirm your position, since this is general information and not legal advice.
Can a new developer take over code someone else wrote?
Yes. Taking over existing code is common work for experienced teams. The key is that it starts with a review rather than new features: setting the software up from scratch, reading the code, and writing down how it works. A team that does that first can pick up almost any project. A team that skips it tends to guess.
Should I finish the existing code or start over?
It depends on what kind of unfinished software you have, and usually the answer differs part by part. Solid code is worth finishing. Fragile code is worth stabilizing first. Code built on shortcuts, or on the wrong foundation, is usually better rebuilt while keeping the designs, data, and requirements. An independent review tells you which is which before you commit.
What if the developer still has all the passwords?
First, ask in writing for access to be transferred. Most hosting companies, domain registrars, and cloud providers also have a recovery process for the legal account owner, which usually means proving your business owns the account. Start with the domain and the code, since those are the hardest to replace, and keep a written record of every request you make.
What should I ask the old developer for if they are still reachable?
Ask for a full copy of the code, access to every account in your business's name, any database backups, the setup steps needed to run the software from scratch, a list of every outside service it uses, and a short note on what was finished and what was not. If there is no rights assignment in your contract, ask them to sign one.
How do I know if the half-built code is any good?
You usually cannot tell from the screens, so look for the signals a review checks. Can it be set up from scratch on a new account? Are there tests? Is the code readable and organized? Are its building blocks current? Were the basics of security handled? An independent reviewer can answer all of that in plain English before any new work begins.
What if my half-built app was made with AI coding tools?
The same approach applies. AI tools are a fast and useful way to build, and they can also produce software that looks finished while the accounts, security, and structure underneath are still thin. A review sorts out which parts are ready to keep and which need proper foundations, so you keep the speed you gained without the risks you did not see.
Can Entexis take over our half-built software and finish it?
Yes. We start with an independent review of the software you have, covering setup, code quality, security, and what it would take to finish. Then we finish, stabilize, or rebuild each part based on what the review found, working in small releases you can see and test. We are also honest when a smaller fix, or a focused rebuild, is the smarter move than finishing everything.
And if you want to understand the kind of custom build that holds up once real customers depend on it, our custom software development page explains how those builds are put together.
A developer walking away feels like a disaster in the moment. In practice, it is usually a setback with a clear way through: secure what is yours, find out what you really have, and restart with a plan you can see working. The businesses that recover fastest are not the ones that rush. They are the ones that stop, check, and then move with confidence.
Stuck With Software Someone Else Started?
At Entexis, we take over half-built and stalled software and turn it into a product you can rely on. We start with an independent review of what you have, then finish, stabilize, or rebuild each part in small releases you can see working, with the documentation that should have been there from the start. When the right answer is a smaller fix rather than a full takeover, we say so. If your project has stalled and you are not sure what you are really holding, let us run you through a no-pressure discovery session. Start the conversation with Entexis.
Need Custom Software Built?
From web apps to enterprise platforms, we build software that fits your workflow, not the other way around. Tell us what you need.
We'll get back within one business day.
Thank You!
We've received your message and will get back to you within one business day.
