Rescue and refactoring
Projects in trouble are a normal part of our work.
The developer left halfway through. The agency stopped answering. The launch date is real and the code isn't ready. We take over web projects in this state and get them moving again.
Signs you need this
You'll recognize at least one of these.
- The person who built it is gone, and nobody else understands it.
- Every small change takes days and breaks something unrelated.
- Deploys are done by hand, and everybody is nervous during them.
- The framework or CMS is several versions behind, and the upgrade keeps getting postponed.
- You've paid for features that were never finished.
- You don't have full access to your own code, hosting or domain.
How a takeover works
Four steps. The first one is small.
Access and inventory
We collect everything: repositories, hosting, domains, databases, third-party accounts. If some of it is missing, we help you get it back. This often turns out to be the most urgent part.
Review
We read the code and the setup, then write down what we find. What works, what's fragile, what's risky, and what it would take to fix. In plain language, with priorities.
Stabilize
Backups, a working deployment, monitoring, the most dangerous bugs and security issues first. The goal is a project you can safely change.
Move forward
Finish the features, fix the rest of the list, or refactor where it pays off. You decide the order with us, based on the review.
Refactoring
Rewrite or refactor?
A full rewrite is sometimes right. More often it means a year of building what you already have, while the old system still needs fixing.
Refactoring is the slower-looking option that usually finishes first. We improve the code in place, one area at a time, and the site keeps running the whole way. Tests go in around the parts we touch, so they stay fixed.
Typical work:
- Splitting large, tangled files into parts that each do one thing.
- Removing dead code and duplicated logic.
- Adding types, tests and linting to code that had none.
- Upgrading frameworks and packages in safe steps.
- Writing down how it all fits together, for whoever comes next.
When we think a rewrite is the better call, we'll explain why, in the review.
Deployment comes with it
Fixing the code is half of it.
Most troubled projects also have a troubled release process. As part of a rescue we usually set up continuous deployment: automated builds and tests, staging and preview environments, and one-click production deploys with a rollback. After that, shipping a fix is routine.
More about continuous deploymentWhat you get from the review
- A written summary of the state of the code, hosting and deployment.
- A prioritized list of problems, from urgent to cosmetic.
- Our recommendation: fix, refactor or rebuild, and why.
- An estimate for the next step.
You can take that review to another team if you want. It's yours.
Send us the project nobody wants to touch.
Tell us what it is, what it runs on and what's going wrong. We'll start with a review.