Challenge
Only one developer knew how to build and deploy it.
Agnotic approach
Documented, automated build and deployment in your own accounts.
Software Project Rescue
Software project rescue services for stalled and abandoned projects
Deadlines keep moving, the app breaks with every release, or the developer has simply stopped answering. Agnotic Technologies takes over the project: we secure your code and accounts, get the current version running, tell you plainly what is worth keeping, and then fix it or rebuild the parts that cannot be saved.
Access secured firstRunning buildSave or rebuild adviceCode you own
Trusted by global innovators
Our software project is stuck. Can you take it over?
Yes. Software project rescue starts with control, not code: Agnotic Technologies first secures access to your repository, hosting, domains and third-party accounts, then gets the current code building and running in an environment you own. Next we review the code, the architecture, the tests and the open issues, and give you a written view of what works, what is risky and what is missing. From there we stabilize the release, fix the defects that block your users, and finish the remaining scope, or rebuild the parts that cannot be saved. You keep the code, the accounts and the documentation throughout.
Developer gone quiet
Our developer stopped responding. What happens to our code?
The code is usually recoverable, and the first job is to secure everything you can reach today. Check which repository, cloud, domain and app store accounts are in your company's name, ask for transfers of the ones that are not, and collect any copy of the code you hold, because a Git clone carries the full history. Agnotic Technologies helps you list the accounts, recover access and confirm the copy you get is complete.
This is practical guidance, not legal advice. Who owns the code and what the developer must hand over depends on your contract and local law, so check the contract with a lawyer if access is refused.
Save or rebuild
Do we need to rebuild from scratch, or can the current code be saved?
Most stalled projects can be saved in part. Rebuild only the parts where fixing costs more than replacing, and decide from evidence gathered in the review, not from the first impression of messy code. These are the findings we weigh.
| What the review finds | Points to saving the code | Points to rebuilding |
|---|---|---|
| Build and deploy | Builds from the repository with documented steps | Cannot be built or deployed without the previous developer |
| Architecture | Clear layers, even if some code is untidy | Business rules, data access and screens mixed everywhere |
| Data model | Tables match the business and hold good data | Data model fights every new feature and needs a migration anyway |
| Tests | Some tests, or code that can be tested as it stands | No tests and no way to add them without rewriting |
| Dependencies | Supported frameworks and libraries that can be updated | Unsupported versions with known security issues and no upgrade path |
| Defects | Bugs cluster in a few modules | Fixing one bug regularly breaks something unrelated |
| Remaining scope | Small next to what is already built | Most of the product is still to be built |
The usual answer is mixed: keep the parts that work, replace the worst module behind a stable interface, and avoid a full rewrite that stops all delivery.
Takeover
How does a project takeover start?
The first steps of every rescue, in order, before any new feature work.
Secure access
Repository, hosting, domains and service accounts moved to your company, with old credentials rotated.
Snapshot
Code, database and configuration backed up, so nothing is lost while we work.
Run it
The current version built and deployed to an environment you own.
Review
Code, architecture, tests, dependencies, security and open issues assessed.
Decide
A written save, fix or rebuild plan for each part, agreed with you.
Stabilize
Blocking defects fixed, a release process set up, then the remaining scope delivered.
Failure points
Why do software projects stall?
Patterns we see in projects that reach us, and what we change first.
Challenge
Accounts were opened in the developer's name.
Agnotic approach
Every account moved to your company, with named admin users.
Challenge
Scope grew while nothing shipped.
Agnotic approach
A short list of what must work for release, delivered first.
Challenge
Each fix caused new bugs.
Agnotic approach
Tests around the fragile areas before changing them.
Challenge
Nobody could see progress.
Agnotic approach
Regular releases to a test environment you can open yourself.
What does a rescue engagement include?
The work we take on, in the order it usually happens.
Access recovery
Accounts, domains and repositories moved into your company's control.
Codebase review
Architecture, code quality, data model, dependencies and security.
Build and deploy pipeline
Automated builds and releases you can run without us.
Stabilization
Blocking bugs fixed and tests added around fragile code.
Partial rebuilds
Modules replaced behind stable interfaces where saving costs more.
Feature completion
The remaining scope delivered in small, testable releases.
Documentation
Setup, architecture and decisions written down for the next developer.
Support after launch
Monitoring, fixes and updates once the app is live.
Related services
Where does a rescue lead?
Rescue often starts or ends with one of these services.
Code audit services
A full written audit of the codebase, when you want the review on its own first.
Application modernization services
When the rescued app runs on old frameworks that need replacing.
QA and testing services
Test suites around the rescued app, so fixes stop breaking other features.
Software maintenance and support
Ongoing fixes, updates and monitoring once the project is stable.
Where it starts
Projects we are asked to rescue
The situations behind most rescue calls.
A freelancer stopped responding
Half-built web or mobile app, with accounts in the developer's name.
An agency relationship ended
Handover of code that only the agency has deployed.
The in-house developer left
A working system nobody else understands.
The launch keeps slipping
A project that is always nearly done, with bugs piling up.
An app store or security review failed
Fixes needed before the app can ship or stay live.
A low-code or prototype outgrew itself
A prototype carrying real users and real data.
Facts and sources
What do Git, GitHub and ICANN documents say about a handover?
Documentation behind the practical steps for recovering code and domains, each linked to its source.
The Pro Git book on git-scm.com explains that in a distributed version control system such as Git, clients fully mirror the repository, including its full history, so every clone is a full backup of all the data.
Source: Pro Git, About Version Control (git-scm.com)GitHub's documentation says that when a repository is transferred to a new owner, the new owner can immediately administer the repository's contents, issues, pull requests, releases, projects and settings.
Source: GitHub Docs, Transferring a repositoryICANN's Transfer Policy requires registrars to give the Registered Name Holder the domain's unique AuthInfo code and remove the transfer lock within five calendar days of the holder's request, where the registrar does not let the holder do this themselves.
Source: ICANN Transfer Policy, section I.A.5.2
Standards
Standards we review rescued code against
OWASP ASVSOWASP Top 10WCAG 2.2OpenAPIGit
Scope
What decides the size of a rescue?
We do not publish prices. These are the drivers we size once we can see the code.
Access
Whether code and accounts are already in your hands.
Codebase
Size, languages, frameworks and how far the code is from buildable.
Platforms
Web, iOS, Android, back end and integrations.
Defects
How many issues block users today.
Remaining scope
What still has to be built after stabilization.
Rebuild share
How much the review says should be replaced.
Engagement
How does a rescue engagement run?
Control first, then a review, then delivery.
1.
Scoping call
You tell us where the project stands and what access you have; we list what to secure first.
Scope2.
Takeover and review
A fixed-scope first stage: access secured, the app running and a written save, fix or rebuild plan.
Review3.
Stabilize and deliver
Blocking fixes, then the remaining scope in small releases, with support after launch.
BuildFrequently Asked Questions
Yes. Messy code is common and often worth keeping. We judge it on whether it builds, whether its structure can be tested and changed, and whether its data model fits, not on style.
Then recovering the source is the first task. If no copy can be recovered, we rebuild from the running app, its database and your documents, and we tell you that plainly before starting.
Yes, if you want us to. A short technical handover can save time, and we keep it to access, setup and known issues.
You do. We work in repositories and accounts in your company's name, and the code, documentation and credentials stay with you.
We do not publish prices. Access, the size and state of the codebase, platforms, defects, remaining scope and the share to rebuild decide the size, and we agree a fixed first stage on the scoping call.