A recurring engagement for us is a client whose original developer has moved on, sometimes amicably, sometimes not, and who needs someone to make sense of what is left before deciding what to do next.
The consistent pattern
Solo-built codebases are rarely badly written in the sense of poor code quality — a single competent person working alone often writes tidy, consistent code, because there was nobody to disagree with them about style. The problems are almost always structural rather than cosmetic.
- No tests, or tests that assert the current behaviour rather than the intended one, written after the fact to pad a coverage number rather than to catch regressions.
- Secrets and configuration mixed into the application code, because there was never a second environment or a second person that made separating them feel necessary.
- One deployment path that exists only in the departed developer's head or on their own machine, with no record of what actually happens between a commit and a live change.
- Business logic that only makes sense with context that left with the person, undocumented because it never needed documenting for an audience of one.
Why this happens even with skilled freelancers
Working alone removes the forcing functions that produce documentation, tests and deployment records as a byproduct of collaboration — there is no reviewer to explain a decision to, no second machine to onboard, no handover ever anticipated. None of this reflects badly on the skill of someone working solo; it reflects the absence of a second person, which is precisely what a single freelancer is.
The gap in a solo-built system is rarely the code. It is everything around the code that a team produces without deciding to.
What we do first
Before writing anything new, we spend time establishing what currently happens in production, verified against reality rather than against whatever documentation exists — a live inventory of environment variables, integrations, scheduled jobs and their actual current state, because assumptions carried over from the previous developer's mental model have been wrong often enough that we no longer start from them.
What we tell clients considering a solo freelancer
Nothing against the practice generally — plenty of well-run projects start that way. The advice is narrower: agree at the start what handover would look like if the relationship ended tomorrow, and revisit that agreement periodically, because the version agreed on day one is rarely the version that would actually help six months in.