How to Take Over an Unfinished Software Project in Egypt and Saudi Arabia (2026 Guide)

"Our developer disappeared and the project is half done — can you finish it?" We get some version of this message from business owners in Cairo, Alexandria, Riyadh and Jeddah. Sometimes the developer was a freelancer who stopped answering. Sometimes it was a small agency that closed, or got busy with a bigger client. Sometimes the team still replies and still promises, but nothing new has actually worked in months. The outcome is the same: payments made, launch dates missed, a demo you can't show a customer, and an owner who isn't sure they even own what they paid for.

The hardest part is that the decision gets made under pressure. The first temptation is to hand the project to the first company that says "we can finish it" — or, the opposite, to throw everything away and start over out of frustration. Either choice can be right. Either can also be the most expensive mistake in the whole project. What makes the difference is an orderly sequence: secure your assets first, get a neutral technical assessment, then decide based on what was actually found rather than on a feeling.

This guide is written for the business owner, not the programmer. It covers the signs a project is genuinely stuck, what to do in the first 72 hours to secure your accounts, code and data, what a code audit covers, a framework for choosing between rescue, rewrite and partial rebuild, how a new team takes over, what the next contract must say, and how to stop it happening again. At Jad Digital we have taken over stalled projects from other teams for years, and we will say plainly when finishing makes sense and when it doesn't.

Delay alone isn't proof of failure. Software projects run late for legitimate reasons — changing requirements, or content that was late on your side. But some patterns repeat in projects that have genuinely stalled, and if you recognise two or three of them, you have a real problem:

If you're early on and only suspect these signs, the fix is sometimes not a new company but a reset of the relationship: a frank meeting, a written plan in short phases, and immediate access to the code. If the developer has vanished or refuses to be transparent, go straight to the next step.

• No live demo for weeks. Every update is a message saying "we're working on it" or a screenshot, never a test link you can open and try yourself.
• Every fix breaks something else. Each bug that gets fixed produces a new one somewhere unrelated — a classic sign of code with no structure and no tests.
• Nobody will give you repository access. You ask for access to the code on GitHub or GitLab and hear "after we finish" or "you won't understand it anyway".
• Deadlines move but never get closer. Each meeting sets a new date, and the announced percentage complete hasn't changed in a while.
• Simple questions go unanswered. Where is the app hosted? Which database does it use? Who owns the Apple Developer account? If the team can't answer clearly, the problem is deeper than a delay.
• Payment requests ahead of delivery. Pressure to pay the next instalment against a promise, not against something you've seen working.
• A revolving door of people. A new developer every month who starts by learning the project from scratch, and nobody who holds the full picture.

Before you look for a new company, and before any heated conversation with the old team, there is one priority: make sure your project's digital assets are under your control. Many stalled projects aren't lost because the code is bad. They're lost because the domain, the hosting account or the store account is registered in the developer's personal name, and a commercial dispute turns into a technical hostage situation.

The simple rule: every account tied to your project should be owned by your company or by you, with the team granted access — never the other way round. Go through this list line by line:

• The domain. Log into the registrar and confirm the account is in your name and email, the transfer lock is on, and the renewal date hasn't crept up without you knowing.
• Hosting and servers. The hosting or cloud account (AWS, Google Cloud or any other provider), and who owns the payment method attached to it. If it's in the developer's name, ask for it to be transferred, or at least for you to be added as an owner.
• The code repository. A repository on GitHub, GitLab or Bitbucket owned by your organisation, with the team invited in. Ask for the full repository with its history, not just a zip file.
• Databases. A recent backup of the production and staging databases, the access credentials, and where uploaded files and images are stored.
• App store accounts. The Apple Developer and Google Play Console accounts should be in the company's name. Moving a published app between accounts is possible but involves a procedure — far easier if you owned the account from the start.
• Third-party keys. Payment gateways, SMS and push notification services, WhatsApp Business API, Google Maps, email services and any paid API. Know where they are and who owns each account, and rotate sensitive keys once the old team is out.
• Designs and documents. Figma or other design files, requirement documents, and whatever documentation exists.

Ask for the assets in writing, in a professional tone, with a clear list like the one above and a reasonable deadline. Avoid threats in the first message; the goal is to get what belongs to you, not to win an argument. If there's money in dispute, separate the financial conversation from the asset handover wherever possible. On legal questions specifically, talk to a lawyer in your country, not a blog post.

Once you have access, change the passwords, switch on two-factor authentication and remove accounts you no longer need. That's basic security hygiene, not an accusation.

With the assets secured, don't ask a new company for a quote to "finish the project" straight away. Any company that gives you a number before reading the code is either guessing or selling. The right step is a scoped technical audit. A serious audit usually covers:

The output should be a written report in language a business owner understands: what exists, what condition it's in, the risks, and a recommendation with its reasons. Some companies overstate how bad the old code is, because a rewrite is a bigger project for them.

• Does it run at all? Can the code be started on a fresh machine from the instructions that exist? Many projects only run on the original developer's laptop because of undocumented settings.
• Code versus what you were promised. A list of required screens and features, each marked complete, partial, missing, or present only as a façade with no logic behind it.
• Architecture and technology. Are the technologies current and supported? Is the code organised in clear layers or one tangled mass? Are there outdated or abandoned dependencies?
• The database. Will the table design and relationships hold up as data grows? Is there real data that has to be preserved?
• Security. Passwords or keys hard-coded in the source, obvious holes in login and permissions, sensitive data left unprotected.
• Tests and quality. Are there automated tests? How much duplication? Can a new developer understand the naming?
• Performance. Slow pages, heavy queries, an app that drains the battery or freezes.
• Environments and deployment. Is there a staging environment separate from production? How do updates go live — by copying files by hand, or through a defined deployment pipeline?
• Documentation. Is there a file explaining how to run and configure the system? Or did all the knowledge live in one person's head?

This is the most important decision in a stalled project, and there's no single answer that's always right. The framework below helps you read the audit's findings.

Rescue means keeping the current code, finishing it and fixing its defects. It makes sense when these conditions hold together:

In that case the new team usually starts with a stabilisation phase — fixing critical bugs, adding a staging environment, documenting how the system runs — before moving on to the missing features.

• The technologies are modern, well known and easy to hire for.
• The core architecture is sound, even if the details have bugs.
• A good share of the features genuinely work and can be tested.
• There are real users or real data on the system, and taking it down would cost your business.

A rewrite means building fresh while reusing the designs, the requirements and what you've learned. Over the medium term it's cheaper when:

What many owners miss: a rewrite doesn't mean everything you paid for is gone. The requirements that became clear, the designs, and your sharper understanding of what your customers want are all assets that shorten the new build.

• The code uses an abandoned or obscure technology that's hard to maintain.
• There's no real structure, and every fix means touching dozens of places.
• The security problems are baked into the foundation, not isolated spots.
• What was actually delivered is a small fraction of what's needed, so fixing it would take longer than building it.

In many projects the answer sits in between: keep the database and the front end, for example, and rebuild the backend — or keep the admin dashboard and rebuild the mobile app. There's also gradual replacement, where each new part is built alongside the old one and then takes its place, so the system keeps running the whole time.

Even when the old team cooperates, moving a software project between teams is a process with steps. A good handover includes:

If the old team won't cooperate at all, the project can still usually be taken over as long as you hold the code and the accounts — but discovery will take longer, because the new team has to rediscover everything that was never written down.

The first thing a professional team does after takeover is change nothing in production. It sets up a staging environment that mirrors production, puts backups in place, and only then starts making changes there. Any team that starts editing the live system directly in week one is repeating the same chaos.

• The complete code with its history in a repository you own, with every branch, not just the main one.
• A setup and configuration guide explaining how to run the project locally, the required environment variables, and the external services it depends on.
• A description of the environments: where production lives, where staging lives (if it exists), and how deployment works.
• The database: a backup, the schema, and any migration scripts.
• A list of known issues and unfinished work.
• Accounts and keys from the 72-hour checklist, transferred into your ownership.
• A knowledge-transfer session if at all possible — even an hour or two with the previous developer, recorded for whoever needs it later.

A stalled project often began with a weak contract, or none at all. Don't repeat that with the new team. A good contract for the next phase makes clear:

That last clause is exactly what would have protected you the first time. Write it while you and the team are on good terms, not after the problems start.

• Code and IP ownership: transferred to you fully, with each payment or on delivery, including designs and documentation.
• The status of the old code: the new team is working on an asset you own, and its responsibility starts from the takeover date — not for earlier defects the audit didn't uncover.
• Phased scope: each phase with testable deliverables and clear acceptance criteria.
• Payment against deliverables: not against an announced "percentage complete", but against a phase you've seen working.
• Ongoing access: your right to the repository and the staging environment throughout the project.
• Confidentiality: protection for your data and your customers' data.
• Warranty and post-launch support: a defined bug-fix period, with anything after that under a separate maintenance agreement, as we explain in website maintenance after launch.
• Termination: what happens if you decide to stop, and how the assets are handed over if you do.

We won't give you numbers here, because the cost of finishing a stalled project depends on factors nobody can know before the audit. These are the factors that actually set the size of the work:

The smartest way to plan is to split what's left into short phases: a defined discovery and audit phase, then stabilisation, then completion phases that each end with a working build. If your requirements aren't written down clearly, now is the time; our guide on how to write a software project brief helps you turn what's in your head into a document someone can actually price.

• The state of the current code: the cleaner and clearer it is, the less time goes into understanding and fixing it.
• The rescue-or-rewrite decision and the amount of building it implies.
• The remaining scope: the number of screens, features and distinct user roles.
• Integrations: payment gateways, shipping, e-invoicing, internal systems.
• Platforms: a website only, or a website plus iOS and Android apps and an admin panel.
• Live data: real users mean careful migration and more testing.
• Documentation quality and cooperation from the previous team.
• Urgency: a hard deadline means a bigger team working in parallel, and that has a cost.

Most stalled projects don't fail suddenly. They stall quietly for months before anyone notices. These practices make the problem visible early, while it's still cheap to fix:

• Repository access from day one. You don't have to read the code, but being in the repository means the code exists, is moving, and is yours.
• A demo every week or two on a staging link you open yourself. The rule: if you haven't tried it with your own hands, it isn't done.
• Short milestones with acceptance criteria. Instead of one large payment for "version one", small phases that each end in something that works.
• Accounts always in your name. The domain, hosting and app store accounts are created under your company from the start.
• Continuous documentation. Make an up-to-date setup guide a deliverable of every phase.
• One owner on your side. Someone who attends the demos, tests, signs off phases and is the single point of contact.

The company that takes over your stalled project needs different experience from one building from scratch. Ask:

The criteria for choosing the company itself are covered in 7 criteria to settle before signing with a software company and in our complete guide to choosing the best software company in Egypt. If your project is in Saudi Arabia, see our guide to choosing a software company in Saudi Arabia; working remotely with a Cairo-based team works well as long as communication and regular demos are clear.

• Have you taken over projects from other teams before? What did discovery look like?
• Do you start with a separate, scoped technical audit before committing to finish the work?
• How do you decide between rescue and rewrite — and would you recommend a rescue even if a rewrite would be a bigger job for you?
• What will you do in the first week after takeover?
• Will I have access to the repository and staging environment the whole time?
• How do the regular demos work, and who is the project manager I deal with?
• What will you take responsibility for in the old code, and what won't you?
• What does the contract look like on ownership, phases and termination?
• Do you work with the technology the project uses? If not, why are you proposing a change?

• Starting a dispute before securing the assets. If things get heated while the domain and accounts are with the other side, you're negotiating from weakness.
• Accepting a completion quote with no audit. A fast number usually climbs after the first two weeks, once the new team finds what it didn't expect.
• Rewriting as an emotional reaction. Frustration with the old team doesn't mean everything they built is bad.
• Rescuing at any cost. Clinging to bad code because you paid a lot for it is the sunk-cost fallacy in its purest form.
• Signing the same contract again. Big upfront payments, no code access, no clear phases.
• Adding new features during the rescue. Stabilise what exists first, then expand.
• Ignoring live data. Any change to a running system needs backups and a staging environment before anything else.

When a stalled project reaches us, we start by helping you secure your assets if you haven't already, then propose a defined audit phase that ends in a written report in plain language and a reasoned recommendation: rescue, partial rebuild or rewrite. If the code can be rescued we say so, even when that makes the job smaller for us. From there we work in short phases, with you in the repository and the staging environment from day one, and you own the code outright.

We take over websites and business systems through our web development service, and mobile apps through mobile app development, for clients in Egypt and Saudi Arabia.