The cheapest software a business can own is a script that does one job, run by someone who understands it. It can also be the most fragile thing in the building, and both statements are often true of the same script.
So “script or product?” is not really a question about technology. By product I mean anything built for people who did not write it: a tool you subscribe to, or an application built properly, with screens, permissions, logs and someone responsible for it. A script is the other end: a file that does the job when the right person runs it. Small VBA tools were among the software I sold in the 2000s, I have built the bigger kind since, and the choice between them keeps coming down to the same four questions.
Two cases, both invented
To keep it concrete, take two hypothetical scripts. The first converts the bank statement export each month into the layout the accounting package imports. One accountant runs it, on the first working day of the month. The second began as a quotation calculator for one salesperson and is now used by eight people in two offices to price every quote the business sends.
Four questions
How many people use it?
The bank script has one user, who knows its habits: it wants the file saved as CSV first, and it stops on an empty statement. Those quirks cost nothing, because the only person who meets them knows them. The quotation script has eight users, and each will find a different quirk on a different day, usually just before a customer call. The moment someone who did not write a script depends on it, it needs plain error messages, checks on its input and a way to run it without knowing where it lives. That is most of the distance between a script and a product.
How often does it change?
Banks change their export formats rarely, and when they do, the import fails on the first run and the fix takes an afternoon. Prices change every quarter, discounts grow special cases, a new product line arrives. If each of those means editing code, the business has turned its developer into a data-entry clerk and hidden its price list where nobody in sales can read it. Whatever changes often belongs where the people who own it can edit it, with a record of who changed what. That is a product feature, and an awkward one to bolt onto a script.
What happens when it fails?
This question settles most cases. When the bank script fails, the import is rejected, the accountant notices within a minute, and nothing has left the building. When the quotation script fails, it may not look like failure at all: it produces a plausible price that is wrong, and the first person to notice could be the customer, or nobody. Loud, harmless failure suits a script. Quiet failure with money attached needs validation, logging and a trail of every change, which is to say a product.
Who maintains it?
Name a person. For the bank script, the accountant can, or whoever wrote it can be asked twice a year. For the quotation script, the honest answer is often “whoever wrote it, and they have moved on.” A script with no maintainer is not cheap. Its cost has been deferred to the worst possible day.
Where the product loses
None of this makes a product the safe default. A bought one brings a subscription, a process bent to fit someone else’s idea of your work, an export you do not control and a vendor with its own priorities. A built one brings screens, logins and tests that a monthly job for one person will never pay back. Rewrite the bank script as an application with a login page and it becomes slower to use, dearer to keep and no more correct.
Often the right answer sits between the two: a script with a product’s habits. It checks its input and refuses a file it does not recognise. It logs what it did and fails loudly. It has a named owner and a page of notes on how to run it and what to do when it stops. Every handover I do comes with the code, the credentials and a runbook in plain English, and on a small script that page does more for its future than any amount of extra code.
Ask the four questions of the bank script and every answer says script: one user, rare changes, loud failure, a named owner. Ask them of the quotation script and every answer says product. Real cases are less tidy, and that is fine, because the questions are not a scoring sheet. They are a way to notice the day a script stopped being one person’s tool and became something the business runs on. Nobody announces that day. No meeting is held when the second salesperson borrows the calculator. But from then on the script is a product, whether anyone built it as one or not, and the only decision left is whether to build it properly before it fails, or after.
