2026-07-22
Script, spec, or tool? How to choose the right fix for your business
Once you know a process needs fixing, the next question is usually the wrong one: "what software should I buy?" The better question is what *format* the fix should take — because for most small business problems, there are really only three options, and the flashiest one isn't automatically the right one.
Why isn't the 'best' fix always software?
A full application makes sense when several people need to use something, on an ongoing basis, without technical help. It's overkill when the real need is 'run this one calculation every Monday morning' — which is a script's job, not an app's.
The mistake is picking the format first (usually "we need an app for this") and only then figuring out whether the problem actually needs one. Flip the order: understand the task, then pick the smallest format that solves it.
What three questions decide the format for you?
| Question | If the answer points toward... |
|---|---|
| Does more than one person need to run this, without asking for help? | A tool or mini-app — a script only one technical person can run doesn't scale past them |
| Is the logic likely to change often, or is it stable? | Frequently-changing rules favor a written spec handed to a developer who can adjust it; stable rules are fine as a script that just runs |
| Do you have anyone on hand who's comfortable running a command or a scheduled job? | If yes, a script is often the fastest, cheapest fix; if no, a small tool with a simple screen is worth the extra build time |
Most small business owners land on "no" to that third question at first — which is exactly why the format matters as much as the fix itself.
What does a script actually get you?
A script is the smallest possible fix: a short piece of code — commonly something like a Python routine, a Google Apps Script attached to a spreadsheet, or a no-code flow built in a tool like Zapier or Make — that runs a repeatable task on a schedule or on demand.
It's the right call when:
- One person (you, or whoever's technical) is comfortable running or scheduling it
- The task is genuinely repeatable — same input shape, same rule, every time
- You don't need a screen or a login for anyone else to use it
It's the wrong call when the task needs to be run by someone non-technical, or when "just run the script" quietly becomes "wait for the one person who knows how to run the script" — which recreates the exact single-point-of-failure problem a fix is supposed to remove.
When is a written spec the right call instead?
A spec is a clear written description of what the fix needs to do — the rules, the inputs, the exceptions, the expected output — handed to a developer to build, rather than built as a quick script yourself.
This is the right format when:
- The task needs a real interface (a form, a dashboard, a login) that a script alone can't provide
- You're hiring a freelance developer or an agency and need something concrete to brief them with, instead of a verbal description that gets reinterpreted
- The fix needs to integrate with another system (an API call to your booking platform, a database read) that's worth building properly rather than duct-taping together
A good spec names the exceptions explicitly — "matches on amount and reference, except when a client bundles two invoices into one payment" — the same way a Quick Check names the exceptions in a workflow, so nothing gets lost in translation between what you meant and what gets built.
Choosing between the three
| Format | Best for | Typical build | Who maintains it |
|---|---|---|---|
| Script | One repeatable task, one comfortable operator | A short script or no-code automation flow | Whoever set it up, occasionally |
| Written spec → built by a developer | A task needing a real interface or system integration | Handed to a freelancer or agency to build | The developer, or whoever inherits the code |
| Small tool / mini-app | A recurring task multiple non-technical people need to run | A lightweight web tool with a simple screen | Needs occasional updates as rules change |
None of these is inherently better. The failure mode is picking the format that sounds most impressive instead of the one that matches who's actually going to use it. A café owner who's the only person touching a task doesn't need a dashboard — they need a script that runs itself. A five-person studio where three staff need to check something daily probably does need the small tool.
If you're not sure which bucket your process falls into, book a call and we'll talk through the specific task — that's a faster way to get a second opinion than guessing from a checklist alone.
Related reading: What automating invoice reconciliation actually looks like for a small business