Hiring someone to maintain an existing app is a different problem from hiring someone to build one, and treating them the same leads to a bad fit. Maintenance is its own skill: working in code someone else wrote, understanding a system before changing it, fixing and extending carefully without breaking the things that already work. Many strong builders are poor maintainers, because they would rather create something new than carefully tend something existing, and they itch to rewrite what they inherit. The developer you want for maintenance is comfortable and even happy working in someone else's codebase, and that temperament matters as much as raw skill.
Key Takeaways
- Maintenance is a distinct skill from building something new.
- The work is understanding existing code and changing it safely.
- Many strong builders are poor maintainers and want to rewrite everything.
- Screen for comfort working in someone else's code, not only greenfield ability.
Maintenance Is Its Own Discipline
Building a new app and maintaining an existing one call for different strengths. Building rewards creating from a blank slate; maintenance rewards understanding what already exists and changing it without breaking it. The maintainer has to read and comprehend code they did not write, respect the decisions and edge cases baked into it, and make careful, surgical changes rather than sweeping ones. This is genuinely skilled work, and it is not what every good builder is good at (the reality of legacy code). A developer who is brilliant at greenfield creation but impatient with existing systems will struggle to maintain your app well, and may do damage by changing things they did not take the time to understand.
Watch for the Rewrite Reflex
The clearest warning sign in a maintenance hire is the urge to rewrite. A developer who looks at your existing app and immediately wants to throw it out and rebuild it is often the wrong maintenance hire, because that instinct leads to risky, expensive rewrites that rediscover old bugs rather than the careful incremental improvement maintenance calls for (the roi of refactoring). The developer you want respects the existing code as something that works and encodes real history, and improves it steadily and safely rather than torching it. Screen for this directly: how do they feel about working in an established codebase, and how do they approach changing code they did not write. Enthusiasm for careful stewardship beats eagerness to rebuild.
| Good maintainer | Poor fit for maintenance |
|---|---|
| Comfortable in others' code | Only enjoys greenfield |
| Understands before changing | Changes before understanding |
| Improves incrementally | Wants to rewrite everything |
| Careful, surgical fixes | Sweeping, risky changes |
A Concrete Version
You need someone to keep an existing app running and gradually improve it. One candidate, a strong builder, looks at the codebase and talks mainly about how they would rebuild it properly. Another, less flashy, talks about how they would first understand the existing system, add tests where they need to change things, and improve it carefully over time. For maintenance, the second is almost always the better hire, because the first will push toward a risky rewrite and grow frustrated with the careful work maintenance actually requires. The skill you are buying is safe stewardship of a working system, and the temperament that fits it is patience with existing code, not eagerness to replace it.
The Honest Counterpoint
Preferring a careful maintainer does not mean rewrites are never right or that builders can never maintain. Some existing apps genuinely do need significant rework, and a maintainer who is too cautious to ever improve the architecture can let a codebase stagnate, so you do want someone who improves it, not merely preserves it. And plenty of strong engineers are good at both building and maintaining. The point is to screen for genuine comfort with existing-code work and wariness of the reflexive rewrite, because the mismatch, a build-loving engineer bored and frustrated by maintenance, is common and costly. Hire for the temperament the work needs, while still wanting someone who moves the code forward.
The Bottom Line
Hiring a developer to maintain an existing app means hiring for a distinct skill and temperament: comfort working in someone else's code, understanding a system before changing it, and improving it carefully rather than rewriting it. Many strong builders make poor maintainers because they would rather create than tend and reach reflexively for a rewrite. Screen for how a candidate feels about established codebases and how they approach changing code they did not write, favor careful stewardship that still moves the code forward, and you get an app that stays healthy instead of a risky rebuild.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
