Sedang Bahagia
Start a projectStart a project

Software project rescue: Get a stalled project running again.

A software project rescue starts with the code: in the first three days we get it building on a clean machine and list every account it depends on. By day 10 we know what works and what is missing, and by day 14 you have a written plan. Then we finish the work in weekly milestones on staging.

Tell us where it standsHow it runs ↓

Day 1: Stalled. The build fails on a clean machine, no one can say which parts work, and most accounts sit with the previous vendor.

Day 3: Running. It builds and deploys to staging from a clean machine, by written steps. Every account it depends on is listed, including three no one had written down.

Day 10: Mapped. Each part is sorted into works, half-works or missing, the backups are restored and checked, and the accounts are moving back under your name.

Day 14: Planned. A short written plan: keep what works, and one milestone a week, each shown on the staging link. Orders and ERP sync come first, the front-end upgrade last.

What a rescue hands back to you.

Each deliverable is something you can open, run or try on staging, set against the problem it fixes. Behind ✦ Explore AI features are optional AI tools our engineers can use on your code: an engineer reviews every output, and nothing is merged unreviewed.

01Days 1–3✦ AI

Build and deploy from a clean machine

The problem:Only the previous developer could build or deploy it.

Before any code changes, we get the project building and deploying, and write every step down so any developer can repeat it.

SETUP.mdChecked on a clean machine
  1. 1Builds from the repository, with no manual edits
  2. 2A fresh database, filled with test data
  3. 3Runs locally against the services it needs
  4. 4Deploys to staging by following the written steps
  5. 5A staging link for the weekly demos

Getting it running also shows which keys are hard-coded and which services no one listed.

✦ Optional AI · engineers review every output
  • Setup steps drafted from the repositoryAI reads the build scripts, CI files and history to draft the setup steps; an engineer proves them on a clean machine.
  • Build errors explainedAI reads the failing build output alongside the code and lists likely causes for the engineer to confirm and fix.
  • Every setting the code readsAI lists the environment variables and settings the code reads, by name and where each is used, so staging misses none.
02Days 1–3✦ AI

Account and access recovery checklist

The problem:Hosting, code or app store accounts registered to the previous vendor.

Every account and service the product depends on, who holds it today, and help moving anything still in the previous vendor’s name.

Accounts checklistHeld by
  • Code repositoryYour company
  • Cloud hosting and databaseYour company
  • Domain, DNS and email sendingYour company
  • Payment gatewayTransfer requested
  • App store accountsPrevious vendor
  • Maps, analytics and API keysYour company

Plus who still has access to each one, for you to remove.

✦ Optional AI · engineers review every output
  • Services found in the codeAI reads the code and config for every outside service it calls, such as payments, maps or email, to complete the list.
  • Transfer request draftsAI drafts the emails asking the previous vendor or a provider to move each account to your company; you edit and send them.
  • Who still has accessAI summarises the user and key lists exported from each service, so you can decide whose access to remove.
03Days 4–10✦ AI

Code and data audit

The problem:No one can say which parts work, so every estimate is a guess.

Feature by feature: what works, what half-works and what is missing, where the data lives, and which parts are safe to keep.

AuditEach part sorted
Keep
Works, readable, has a clear purpose
Repair
Mostly works, with known gaps
Rewrite
Unreliable, unreadable or unsafe
Remove
Unused, once nothing calls it
Also checked
  • Database structure
  • Duplicates and broken records
  • Backups, by restoring one
  • Outdated libraries
  • Sessions with users
✦ Optional AI · engineers review every output
  • A map of the codebaseAI drafts a summary of each module, what it does and what it depends on, for the engineer to check against the code.
  • Dependency and dead-code reportsTools find outdated libraries and code nothing calls; AI explains what each finding affects, and an engineer checks before anything is removed.
  • Error-log summariesAI groups production errors and suggests likely causes for an engineer to confirm, so the audit starts from real failures.
  • Data checks in plain wordsQueries find duplicates and broken records; AI writes up what they mean, with examples, for your team to confirm.
  • User sessions into findingsAI turns notes from sessions with the people who use it into findings per feature, which we check with them.
How we sort the code →
04Days 11–14✦ AI

Written recovery plan with weekly milestones

The problem:Status reports instead of demos, so problems surfaced late.

A short written plan you can check: where things stand, the risks ranked, and one milestone a week to try on a staging link.

Recovery planShort, and checked weekly
  1. 1Where things stand: keep, repair, rewrite and remove
  2. 2The risks, ranked, with what we do about each
  3. 3Weekly milestones, each one shown on staging
    • W1Orders and ERP syncOn staging
    • W2 · this weekPayments
    • W3Reports and emails
    • W4Front end, stage 1
  4. 4What is deferred, and why
  5. 5What we need from you, and by when

Every Friday, that week’s milestone is on the staging link for you to try.

✦ Optional AI · engineers review every output
  • Findings grouped into a draft planAI groups the audit’s findings into candidate milestones; the technical lead sets the order, scope and estimates.
  • Weekly demo notesAI drafts what changed this week from the merged work, with the staging link; the lead edits it before you see it.
  • Risks kept currentAI drafts new findings into the risk list as the work goes on, for the technical lead to rank and answer.
What the plan contains →
05In the milestones✦ AI

Legacy stack upgrades and migrations

The problem:A framework version that no longer gets security updates.

We split each upgrade or migration into stages and release one at a time, so people keep using the product throughout.

Front end, in stagesFrom week 4

Stage 1: Tests first. Tests record what each screen does today, before any code changes.

Stage 2: First screen. Orders moves to React. Users keep the same address, and the other screens still run on AngularJS.

Stage 3: One by one. Products and invoices follow, one release at a time, each one shown on staging first.

Stage 4: Switch-off. Admin moves last and AngularJS is switched off. The product stayed live for its users at every stage.

Framework versions are upgraded one step at a time, and data migrations are rehearsed on a copy before the real move.

✦ Optional AI · engineers review every output
  • Tests that pin down current behaviourBefore any change, AI drafts tests recording what the system does today; engineers review them, and they must pass at every stage.
  • Migration drafts, reviewed line by lineAI drafts each screen’s move to the new framework, reviewed line by line by an engineer and merged only once the tests pass.
  • Upgrade notes per libraryAI reads each library’s release notes for breaking changes and lists the files they touch, for an engineer to check.
  • Data mapping for the moveAI drafts the mapping from old tables to the new schema; an engineer reviews it, and code compares row counts and totals.
Web apps on a stack your team can keep →
06Throughout✦ AI

Documentation for the next developer

The problem:Setup steps and decisions that lived in one person’s head.

Written as we go and handed over with the code, so the next developer, ours or yours, can set it up and change it safely.

docs/In your repository
  • README.mdWhat it does and who uses it
  • SETUP.mdFrom a clean machine to staging
  • ARCHITECTURE.mdHow the parts fit together
  • DATA.mdWhere the data lives, and restoring backups
  • ACCOUNTS.mdEvery service, and who holds it
  • DECISIONS.mdWhat changed, and why

Your own developers, or another team, can start from these and the code without needing us.

✦ Optional AI · engineers review every output
  • Documentation draftsAI drafts setup, architecture and module notes from the code; the engineer who did the work checks and corrects them.
  • Docs that change with the codeAI drafts the matching documentation update in each pull request, reviewed with the code before it is merged.
  • Answers that cite the fileAI answers how something works from the repository and its docs, pointing to the file, or says it is not documented.
  • Incident notes draftedAfter a production issue, AI drafts a note for the docs: what happened, the fix and how to check it, for an engineer to edit.
What a handover includes →

Every rescue starts the same way: we get it running, then tell you plainly what we find.Tell us where it stands →

The first two weeks of a rescue.

For companies in Singapore, Malaysia and Indonesia, in English and Bahasa Indonesia. You talk to the technical lead throughout, from the first call to handover.

14 days · 3 steps
Days 1–3 · 3 days

Get it running

We get the project building and deploying from a clean machine, and list every account and service it depends on.

Days 4–10 · 7 days

Map what exists

We map what works, what half-works and what is missing, where the data lives, and talk to the people who use it.

Days 11–14 · 4 days

A plan you can check

You get a short written plan with weekly milestones, each one demonstrable on a staging link. Then we finish the work on that plan.

How we work

Facts before fixes

Nothing is rewritten in the first days. We get the project building and deploying first, because code you can’t run can’t be judged.

Keep what works

We sort the code into what works, what half-works and what is missing before anything is rewritten. The plan builds on the parts that already work, such as the data model or an integration.

Accounts back under your name

We list every account and service the product depends on and help you move anything still registered to the previous vendor.

Progress you can see

After the plan, we demonstrate every milestone on a staging link, so you judge progress by what you can try rather than by status reports.

Project stalled? Tell our technical lead where it stands.

Tell us where it stands →

Questions about project rescue

Should we rewrite it from scratch?

We rarely recommend rewriting all of it. The first two weeks show which parts are safe to keep and which have to be rewritten.

What do you need from us to start?

Access to the code repository, hosting, database and third-party accounts, plus whatever documentation exists, even if it’s out of date.

Can you take over a system on an old stack?

Yes. Where an upgrade or migration is needed, we plan it in stages, so the product keeps running for the people who use it.

Do you use AI on our code?

Only if you agree. Our engineers can use AI tools to map the code, draft tests, documentation and migration changes, and summarise error logs. An engineer reviews every output and nothing is merged unreviewed. We use enterprise model APIs whose terms exclude training on your code.

Do we own the source code?

Yes. You own 100% of the source code from the first commit, and at handover you receive the code, the documentation and admin access.

Who will we talk to?

The technical lead who does the work, with a domain specialist who has done this kind of work before. We reply within 24 hours, there’s no account manager in between, and we sign an NDA on request.

From the build

Book a call