When a Django Build Will Not Pay

Four reasons to stop

1. A product covers most of it — buy it, build only the gap
2. The process is about to change — you would be encoding something you are discarding
3. Nobody will maintain it — an unmaintained application becomes a liability
4. The volume cannot repay it — do the arithmetic before going further

The right question is not whether a product does everything. It is whether the gap costs more than a build plus three years of maintenance.

Do the arithmetic honestly

• Frequency multiplied by time multiplied by hourly cost
• Plus error costs where they are real and countable
• Against build plus three years of hosting and maintenance
• Counting only time that would actually be redeployed
• Being conservative on saving and generous on cost

What to do instead

The maintenance question

An application nobody maintains becomes a liability within two years: unpatched, unchanged, and increasingly divergent from how the business actually works.

If you cannot name who will own it and who will maintain it, resolve that before commissioning anything.

We say this reasonably often

Recommending against a build loses us work and it is the correct answer often enough that we make it a habit.

A system that cannot pay for itself damages the relationship, the reference and eventually the client's appetite for any technology project.

Frequently asked questions