Case Study

🔧 Project Rescue

Previous Team Gone.
No Backup. No Docs.
One Month to Live.

Crystal Networks had a firm go-live deadline one month away. The development team that had been building the project became unreachable — no handover, no documentation, no code backup. The client had only their running production instance. We were handed an unknown codebase, an immovable deadline, and a business that was counting on us. We delivered.

CRYSTAL NETWORKS · RESCUE · DELIVERED

● Launched on time

DEADLINE

Days from day 1

Backups / docs

✓

Delivered

SITUATION ON DAY ONE

Previous team — unreachable, no handover

Gone

Documentation — none

None

Code backup — none. Only running instance.

None

Deadline — 30 days. Immovable.

Fixed

OUTCOME

Launched within one-month deadline

Delivered

2+ years of continued development post-rescue

Success

Business secured strong subscriber growth

Growth

✦

THE MOST CONSTRAINED RESCUE WE'VE HANDLEDEvery rescue is difficult. This one had every constraint at once — time, information, access. We delivered anyway.

Days from engagement to go-live — an immovable deadline with every constraint stacked against it

Documentation, backups, or handover from the previous team. We worked from the running instance only.

2yr

Post-rescue development — continued building the platform for two years after go-live

Sold

The business was eventually sold — a successful exit built on a platform we rescued and grew

Client Crystal Networks

Service Project Rescue & Recovery

Deadline 30 days from day one

Documentation None

Outcome Delivered · 2+ years post-rescue · Business sold

— The Situation

Every constraint at once.

Some rescue projects have one major constraint — a tight deadline, or a missing team, or no documentation. Crystal Networks had all of them simultaneously.

👥

Previous Team

Unreachable. No handover meeting. No documentation package. No code walkthrough. No way to ask a question about any part of the system.

📁

Code & Documentation

No code backup. No architecture documentation. No database schema. No deployment notes. The client had one thing: their running production instance.

⏰

Deadline

30 days. Not negotiable. The go-live date had been communicated to customers and stakeholders. Missing it would cause significant reputational and commercial damage.

The client came to Infomaze with everything stacked against them. Their previous team had built something — they could see it running — but had no way to understand it, modify it, or safely extend it. And they had 30 days until a go-live date that couldn't move.

Most development teams would decline this engagement. The risk is high, the information is minimal, and the timeline is unforgiving. We accepted it — because we had the experience to map an unknown codebase from what it does rather than from what someone tells us it does, and because the client genuinely needed someone who could.

// What we had to work with on day one

✗No repository access — working from a live environment only

✗No database schema documentation

✗No architecture or design decisions recorded

✗No contact with anyone who had built it

~Client knowledge of what the system should do — limited but present

✓Access to the running application — the only source of truth

— The Rescue

Four weeks. One running instance. Everything else inferred from code.

The approach was triage-first. Understand what exists, identify what's critical for go-live, fix what's broken, defer what isn't essential. Every day had to produce something that moved the needle toward a launchable product.

Week 1

Codebase archaeology — mapping what exists

No documentation means the code is the only source of truth. Week one was entirely focused on reading and mapping — what does this application do, how is it structured, what are the database relationships, where is the business logic, what is clearly broken vs simply unfinished. Everything inferred from the running code and the running application.

Code structure mapping Database schema reverse-engineering Critical bug identification Missing feature inventory Go-live scope agreement

Week 2

Critical fixes and go-live scope locked

With the system mapped, we agreed with the client what "go-live" meant given the timeframe — some features that were planned for launch were deferred to post-launch. This was an honest conversation: here is what we can safely deliver in the remaining time, here is what we cannot. Scope discipline in a rescue is essential — trying to do everything in 30 days would have resulted in delivering nothing properly.

Critical bug fixes Go-live scope agreed Post-launch backlog defined Architecture issues triaged

Week 3

Stabilisation and testing

With fixes in place and scope locked, week three was stabilisation — testing every critical user journey against the agreed go-live scope, finding the issues that only appear under realistic usage rather than isolated testing, and fixing them. Working from a live environment without a proper development copy added risk that had to be managed carefully — every change tested against the production instance.

End-to-end journey testing Edge case identification Performance baseline Data integrity checks

Week 4

Go-live preparation and launch

Final preparation — launch checklist validated, client walkthrough of the agreed go-live scope, any last-minute issues resolved. The launch happened within the 30-day deadline. It wasn't perfect — the deferred features were still missing, and the architecture had issues we planned to address in the post-launch phase. But it was stable, it was functional, and it worked for the customers who needed it to work.

Launch checklist Client sign-off Go-live execution Post-launch monitoring

// What was achieved within the 30-day deadline

Launched within the one-month deadline — the commitment that mattered most was kept

Critical bugs identified and resolved — the application was stable for go-live

Go-live scope agreed honestly with the client — no false promises about what could be done

Post-launch backlog defined and prioritised — the work that continued after launch was structured

Documentation produced — the codebase was no longer undocumented after we finished

— What Came After

Two years of development. A business sold.

The 30-day rescue was just the beginning. After launch, Crystal Networks continued with Infomaze as their development partner — adding the deferred features, improving the architecture, building the subscriber base, and growing the platform.

Over two years of continued development, the platform attracted strong subscription growth. The business was eventually sold — a successful exit that would have been impossible without the rescue that made it launchable in the first place.

This is one of the patterns we see in rescue engagements: the acute crisis gets the attention, but what the client really needed was a development partner they could trust for the long term. We became that for Crystal Networks.

Timeline summary

Day 1

Engagement starts. Unknown codebase. 30-day deadline.

Week 1

Codebase mapped. Critical issues identified. Scope agreed.

Week 4

Launched. Stable. On deadline.

Month 2–26

Continued development. Subscriber growth. Features added.

Exit

Business sold. Successful outcome.

✦ The lesson

Code always tells the truth. People sometimes don't.

The most important skill in a rescue engagement is the ability to read an unknown codebase and understand what it actually does — not what someone says it does, not what the spec said it should do. The code is the ground truth. 23 years of engineering experience means we can read that truth faster than most.

Previous Team Gone. No Backup. No Docs. One Month to Live.