# Taking over a module left unfinished by another contractor

> A half-finished module, a developer who no longer replies, a store that’s waiting: the question isn’t «can you finish it», but «what is actually in this code», and nobody can answer that without reading it.

- Source canonique : [https://allaux.fr/en/modules/reprendre-un-module-inacheve](https://allaux.fr/en/modules/reprendre-un-module-inacheve)
- Langue : EN
- Dernière mise à jour : 2026-08-03

## 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.

## The four points that decide between finishing and rewriting

1. **Is the architecture the platform’s own** — A module that respects the install lifecycle, the hook points and the platform conventions can be finished. One that writes straight into core tables, bypassing the intended objects, gets rewritten, because every upgrade will call it into question.
2. **Is the code readable** — Consistent naming, display separated from processing, no blocks copied ten times over. This isn’t about elegance: it decides whether a fix takes an hour or a day.
3. **What does it do with data** — Unescaped queries, data stored without constraints, no error handling at all: those three signals alone often justify a rewrite, whatever the apparent progress.
4. **How much is genuinely done** — A module that renders a screen is not a module that works. I test real cases before believing the stated progress.

## 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.

## First, check what you still have access to

> Recover the server credentials, the database, the code repository if there is one, and the third-party accounts the module uses. A contractor who stops replying is one problem; a contractor who is the sole holder of a production access is another, more serious one, and it gets settled before any talk of code.

## Related pages

- **Maintenance and managed support** — What must be in place afterwards so a module doesn’t become orphaned again. ([/services/maintenance](/services/maintenance))
- **Auditing a store’s module estate** — The full inventory when several builds have followed one another without continuity. ([/modules/audit-du-parc-de-modules](/modules/audit-du-parc-de-modules))
- **What really drives the price of a custom module** — Why a takeover isn’t priced like a fresh build. ([/modules/ce-qui-fait-le-prix-d-un-module](/modules/ce-qui-fait-le-prix-d-un-module))
- **Urgent e-commerce troubleshooting** — If the store is blocked in production while the takeover is being organised. ([/services/depannage-urgent](/services/depannage-urgent))

## FAQ

### Will you take over someone else’s code?

Yes, it’s a regular part of my work. I simply won’t commit to a fixed price before reading it: I first propose a capped diagnosis, with a written report, and then a quote.

### The module isn’t documented at all, is that a blocker?

No. Missing documentation is the rule rather than the exception. What genuinely blocks is encoded code and no server access: without readable code there is nothing to take over.

### Can I recover work I have already paid for?

Technically yes, if you have the files deployed on the server: those are what count, not what was promised. Legally it depends on your contract, and that isn’t my field.

### How long does the diagnosis take?

It depends on the size of the module, but it is always capped in advance: I set a maximum before starting and stick to it, even if the conclusion is that reading alone isn’t enough.