When building a small tool makes more sense than buying one

When your delivery rates depend on Algerian wilayas rather than zip codes, or your order flow comes through WhatsApp instead of a checkout page, the shelf stops fitting. Off-the-shelf tools are built for markets where those conditions are exceptions. For a business operating locally, the exception is the rule — and the gap between what exists and what you need is where a small build earns its place.

This is not an argument for building everything. Most workflows — payroll, accounting, file storage — are generic enough that renting them is the right call. The question is how to tell which ones are not.

What off-the-shelf actually buys

A packaged product is a set of decisions someone else made about what a customer is, what an invoice contains, how stock moves, and which rules apply. Buying it means accepting those decisions. When they match your business, that is a bargain: years of other people's mistakes and fixes, maintained by a team you do not employ.

The cost is hidden in the constraints. A per-seat licence decides who sees which records. A module price pushes you toward fewer users than the work actually needs. When the package requires a connection you do not always have — a warehouse with no reliable network, a driver on the road with one bar — it degrades quietly rather than telling you.

When a small build is the honest answer

A custom tool is justified by a specific kind of difficulty: a workflow that carries real money and does not match any standard shape.

Watch for these signals:

• The real process lives in a spreadsheet beside the package. If the spreadsheet is the system, you are already maintaining custom software — it just has no error handling and no owner when the author leaves.
• A rule that no package expresses: pricing by wilaya and season, stock reserved per contract, delivery fees that include a return leg. Configured rules cover common shapes; they stop where your competitive advantage starts.
• The work is small but recurring. A script that reads a file, applies a rule, and writes output can replace an hour of manual work without becoming a platform.
• The cost of the subscription is not the only cost. Per-user pricing, currency conversion, and the time lost to workarounds add up over three years. Comparing them on the same timeline usually reveals the truth.

The cost nobody puts on the invoice

Building is not free. A prototype built in a weekend costs time, and production work costs more: hosting, backups, the certificate that expires, the person who must be able to read the code when the original author is unavailable. A custom tool without a second reader is a dependency, not an asset.

If the workflow is not stable, a build freezes the wrong version. A business that changes its process every quarter should rent until the shape settles. If the answer to "will this exist in two years" is no, do not build.

The comparison is not price against price. It is which risk the business is better placed to survive: a vendor changing direction, or a developer becoming unavailable. That is a judgement for the owner, not the spreadsheet.

A decision rule

Before comparing costs, write the workflow on one page: what starts it, what it produces, who approves it, what happens when it goes wrong. Show it to a vendor and ask them to model it in a demo — not describe it, show it. If both can show it working, buy the package. If both need a workaround, you have measured the gap, and that page is the first document any custom build needs.

A simple framework for deciding:

1. Identify the friction. What task takes longer than it should, every week, with the same steps?
2. Build the minimal version — one feature that removes the biggest pain. Not the full product.
3. Launch it for internal use first. If it genuinely makes the work easier after a month, it may have value beyond one user.
4. Decide if it stays a personal tool or becomes a product. If the maintenance exceeds the value, keep it internal. If others ask for access consistently, the problem is real and the build is justified.

The anti-pattern is the opposite: building for a problem you do not personally feel. A tool that solves an imaginary pain produces an interface nobody uses and a maintenance cost nobody planned for.

If the gap is small — one filter, one lookup table, one scheduled report — a script is probably enough. If it touches how money moves, how orders close, or how customers are served, it deserves a proper build. The middle — a spreadsheet with a script beside it — is usually the worst of both worlds.

Where this stops

This advice applies to operational work inside a small business: recording, reporting, ordering, pricing. It does not transfer to production lines, regulated processes, or anything where volume is measured against a fixed sequence. It assumes someone will own the result after handover; without that, the honest recommendation is a subscription, even a bad one.

We build the small custom side — the modules that decide whether a month closes correctly — and integrate with what a business already owns. If a package fits, we say so. A system nobody needs is the most expensive kind to maintain.