My Developer Keeps Breaking Things — Is It Them or the Code

Something breaks. Your developer fixes it. Something else breaks. They fix that. A third thing breaks. At this point you are not sure whether you have a bad developer or a broken codebase and you do not have the technical knowledge to tell the difference. This is one of the most disorienting situations a non-technical founder can be in because the thing you are trying to evaluate is the same thing you are depending on to tell you what is wrong.

The honest answer is that it is almost always both. A fragile codebase and a developer who is not equipped to work in it are a combination that produces exactly the pattern you are describing. Understanding which is the bigger factor tells you what to fix first.

What a Codebase Problem Looks Like

A fragile codebase is one where changes in one part of the system have unpredictable effects on other parts. This happens when the code was written without a clear separation between different pieces of functionality, when the same logic is duplicated in multiple places, or when there are no tests to catch when something that was working stops working.

In a fragile codebase, even a skilled developer will break things. They will fix the auth bug and discover that the fix changes the behaviour of the session handling in a way they did not expect. They will update the payment flow and find that the change affects how user roles are assigned. These are not developer errors in the ordinary sense. They are the natural consequence of working in a system that was built without the architecture to contain change.

The signal that the codebase is the primary problem is when different developers keep producing the same pattern. If you have had two or three developers work on the product and all of them have experienced the same breaking cycle, the common factor is the codebase, not the people.

What a Developer Problem Looks Like

A developer who is not equipped for the situation will also produce the breaking pattern, but for different reasons. They may be fixing symptoms rather than causes. They may be making changes without understanding the full context of what the change affects. They may be working in a stack or architecture type they are less familiar with than they represented.

The signal that the developer is the primary problem is when the breaks are concentrated in areas the developer has recently touched rather than distributed across the system. If everything was mostly stable until a specific developer started working on the product, and the instability tracks closely with their changes, that is a developer problem more than a codebase problem.

Another signal is how they communicate about the breaks. A developer working in a fragile codebase will typically be able to explain what happened, why the fix caused the new problem, and what they would need to do to prevent it from recurring. A developer who is out of their depth will give vague explanations, avoid specifics, or attribute the problem to the code without being able to explain the mechanism.

How to Tell Which One You Have

You do not need to read the code to distinguish between these two situations. You need to ask three questions.

Ask your developer to explain the last break in plain language. Not jargon, not technical terminology. What happened, why it happened, and what they did to fix it. A developer working competently in a fragile system can explain this clearly even if the explanation is uncomfortable. Something like: the auth fix changed how session tokens are validated and that broke the user role check in a different part of the code. We did not catch it because there are no tests covering that interaction. A developer who is struggling will give you a vague answer or change the subject to how complicated the code is.

Ask how long it takes to add a small, well-defined feature. Not a complex new workflow. Something genuinely small, like a new field on a form or a new filter on a list. In a healthy codebase with a competent developer, a small feature takes a day or two. In a fragile codebase, the same feature takes a week because every change requires extensive testing across unexpected dependencies. If small things consistently take far longer than they should, the codebase is the primary constraint.

Ask what the developer would do to make the system more stable. A developer who understands the problem will have a specific answer. They will point to the parts of the system that need to be refactored, the tests that need to be written, the architectural decisions that need to be revisited. A developer who does not understand the problem will either say everything is fine or say that the whole thing needs to be rebuilt.

What to Do With the Answer

If the codebase is the primary problem, the right response is a technical audit before any other decision. You need to understand which parts of the system are actually fragile, which parts are solid, and what specific interventions would stabilise it. Without this, you are guessing about what to fix and the breaking cycle continues regardless of who you hire.

If the developer is the primary problem, the right response is not necessarily to replace them immediately. The first step is a direct conversation about what you are observing. Tell them specifically what you are seeing: you have noticed that in the last four weeks, every fix has produced a new break, and you need to understand what is causing this. Their response to that conversation will tell you more than anything else whether the relationship is recoverable.

If both are true, which is the most common situation, you need a technical audit of the codebase and a clear decision about the developer. Stabilising a fragile codebase with a developer who does not understand it is possible but slow and expensive. A new technical team inheriting a properly documented codebase with a clear roadmap produces much faster results than either fixing the code or replacing the developer in isolation.

Forgex Systems (forgex.systems) works specifically in these situations. The starting point is always understanding what is actually in the codebase before deciding what or who needs to change.