Most teams already pay for a tool that almost fits. Building is the right bill when the almost is the part of the work that makes the money, and it is the wrong bill when a careful setup would have done.
Write the job the tool cannot finish
List the steps a person takes today, and mark the ones the current tool already does. The remainder is the candidate for software. If the remainder is a missing report, ask whether the tool can export and a spreadsheet can finish it. If the remainder is the sale, the stock movement, and the receipt, you are describing a system, not a report.
Count the people and the exceptions. A tool that works for one branch and collapses at three is a reason to build or to change tools, and you should price both. A tool that works except for one person’s habit is a training problem. Building software to avoid a conversation is expensive training.
The cost of almost
Add up what you pay for the tool, the hours spent working around it, and the errors those workarounds cause. A double entry between the tool and a sheet is a cost even when nobody calls it a cost. Put a number on a month of it. That number is what a build has to beat, not a feeling that the tool is old.
A build has its own almost. The first release will not cover the exception you forgot. Budget a period after launch for the real exceptions, and name who will sit with the users. A quote that ends on go-live is a quote that has not met the work.
Decide in writing
The decision is a page: stay and configure, switch to another product, or build the slice that the products do not cover. Each option has a price range and what it will not do. The page is what you send to the person who has to approve the spend, so the project does not restart when they ask why you did not just use the tool.
If you build, keep the tool for the part it is good at and integrate, or leave it with a date. Running both forever, with people copying between them, is the outcome you were trying to escape. Name the date the copy stops.
The page that decides
Write the steps a person takes, and mark the ones the current tool already finishes. The unmarked steps are the candidate for a build. If they are a missing report, ask whether an export and a sheet would do. If they are the sale, the stock movement, and the receipt, you are describing a system. A tool that fails because of one person's habit is training, not a build.
Price a month of the workaround: the licence, the hours copying between systems, and the errors that copying causes. A build has to beat that number, not a feeling that the tool looks old. Also price the build's own almost. The first release will miss an exception. Budget time after launch with the users, or the quote ends before the work does.
The decision is a page the buyer can forward: stay and configure, switch product, or build the slice products do not cover. Each option has a range and a list of what it will not do. If you build, name the date the old tool stops being copied into. Running both forever is the outcome you were trying to leave.
Bring that page to the first call. It is a better brief than a list of features, and it keeps the project from restarting when a director asks why you did not just use what you already pay for.
Before you commission a build
- Mark which steps the current tool already completes.
- Price a month of the workaround, not only the licence.
- Write the decision as stay, switch, or build, with a range.