Questions to ask before handing over a broken system

When your system breaks or limps along with bugs, the instinct is to hand it over and hope the developer makes it right. But handing over a broken system is a transaction where clarity up front prevents recriminations later. The real risk isn't asking too many questions—it's asking too few, or accepting vague answers. A developer who can't or won't explain what they're doing, why, and what happens next is a red flag. This guide gives you the exact questions to ask and how to read the responses.

What do you do first—look or diagnose?

A good developer should describe a diagnostic process before committing to a fix. They might say, "I'll run through the error logs, check the database for corruption, and trace the user flow that triggers the problem." They should mention tools or methods. An evasive answer sounds like, "Oh, I'll just get into it and see what's broken." That suggests they're guessing, not investigating.

Why this matters: A real diagnosis takes time and costs less than trial-and-error fixing. If someone avoids explaining their process, they may be planning to charge you for every fix they throw at the wall. Ask how long the diagnosis typically takes and whether it's charged separately. A strong answer includes a time estimate and clarity on what happens if the diagnosis reveals something unexpected.

Will you tell me what caused the break and why it matters?

After they fix it, ask them to explain the root cause in a way you can understand. A good response acknowledges the technical detail but translates it: "The system was checking user permissions at the front end only, not the back end. An attacker or a glitch could bypass that. I've added a server-side check so it's enforced everywhere now." Evasive: "It was a bug in the logic."

An explanation matters because it tells you whether the problem was careless code, an edge case no one foresaw, or a design flaw. It also shapes what you ask next. If it's a design flaw, a "quick fix" might not be enough. If it's a one-off coding error, a proper review and test might prevent it recurring.

How will you test the fix before handing it back?

Listen for specifics. "I'll run the automated test suite, then manually test the exact scenario that caused the error, then test a few nearby features to make sure I didn't break anything else." That's thorough. Vague: "I'll test it and make sure it works."

Ask whether they'll involve you in the testing or whether you can run it in a sandbox first. A developer who wants you to catch their mistakes in production is cutting corners. Also ask what their rollback plan is if something goes wrong—do they have a backup, a way to reverse the change, or a version control system they can revert to? If they don't know, that's a risk.

What happens after the fix—am I on my own?

This is where maintenance clarity kicks in. Ask whether the fix includes any follow-up: monitoring, a patch schedule, or a review in a few weeks. Some bugs hide until you're under load or seasonal use patterns hit. A developer who says, "I'll keep an eye on the logs for a week after deployment" is thinking beyond the handoff.

Also ask what support you get if the fix doesn't hold or a related bug surfaces within a reasonable window. A week? A month? Understanding the boundaries prevents frustration. If they won't commit to any follow-up, push back. A well-managed fix should include at least a brief check-in.

Before you hire, ask to see a recent example of how they diagnosed and fixed a similar problem. Not a portfolio—an actual case study. A credible developer should be able to walk you through their thinking. When you're confident in their process and their willingness to explain it, you're ready to hand over the keys. On Strove, you can review developer profiles, compare their track records, and read other clients' feedback—exactly the vetting that turns hiring from a gamble into an informed decision.