Taking over a module left unfinished by another contractor

What I collect before saying anything

I ask for three things: the complete module code as deployed, read access to the store it runs on, and a description of what it was meant to do. The third is nearly always missing, and it is the most useful: without it, you cannot tell deliberate behaviour from a bug. A half-built feature looks a great deal like a broken one.

I then check what was delivered beyond the module folder: class overrides dropped elsewhere, tables added to the database, scheduled jobs on the server, API keys stored somewhere. An unfinished module has usually left pieces outside its own folder, and those are what cause trouble later.

Finishing sometimes costs more than starting again

It’s counter-intuitive and I still say it regularly: picking up code you didn’t write means first understanding all of it, including the parts you will never touch. On a modest module, that reading time can exceed the time to write a clean version. When that is the case, I say so, with the reasons, and you decide.

Conversely, when the base is sound, taking over is much faster than starting again: the functional choices are made, the specifics of your business are already captured in the code, and what remains is finishing and hardening. I meet both situations, about equally often.

Either way, a takeover ends the same way: a module you could hand to someone else. Complete sources, identified dependencies, a written installation procedure. Precisely what was missing at the start.