Finish a stalled software project or start again: what decides it

Every owner of a half built application feels the pull of the invoices already paid, and that feeling is real, but it tells you nothing about the code. A costly project can be unusable. A cheap one can be a good base.

Ask a different question. If a competent team received this repository for free tomorrow, would they build on it, or would they bin it and start from a blank folder? Answer that honestly and the decision usually follows.

Get a written review from a stranger. Two days of reading beats two months of hoping.

Screens can be redrawn in a week. A badly shaped database cannot. Open the schema first. Read the tables, the foreign keys and the migration history. Then ask whether customers, orders and invoices are separate things, or one wide table with columns called field1 and field2.

Then run the finished modules with real sample records. Create an order, edit it, delete it, export it. A module that survives this is worth keeping. One that crashes on a blank date field is a warning.

Note which modules are truly complete. Some only look it. A login screen with no password reset is the usual culprit.

Find the framework and runtime versions in the package file or composer file. If they reached end of support years ago, finishing the project means upgrading first, and that cost belongs in your comparison. A current version is a good sign.

Look for automated tests. Even a thin set shows that the developer cared whether changes broke things, and that care is worth more than the tests themselves. No tests at all? Every new feature becomes a gamble.

Ownership comes next. Is the repository in your account, or on the developer’s laptop? Do you hold the domain, the hosting login, the app store account and the third party API keys, or does a former contractor still control them? Missing keys can be replaced. Missing legal rights to the code cannot, so settle that in writing.

Sit with the people who will use the system and read the original requirement document line by line, marking each one as still true, changed or dropped. If most lines changed, the code answers a question you no longer ask.

Count what the business now needs that the project never planned for: a second warehouse, a new tax rule, a customer portal. Bolting these onto a weak base costs more than designing them in.

Be fair to the old work too. Reusable parts often survive a restart, such as the database design, the label printing code or the integration with your payment gateway.

Score the five tests in plain words: data model, finished modules, framework age, test coverage and ownership. Add a sixth line for requirements. Two or more failures point to starting again. One failure usually means finish.

Ask the same reviewer for two estimates, one for finishing and one for rebuilding, and compare the time to a first working release, not only the total. A rebuild that salvages the schema and the design assets can be quicker than it sounds.

Take the scorecard to your next meeting. Decide there.