When the right answer is not to build software at all

A shared calendar with colour codes, a web form that emails a PDF, a sheet that totals hours by job. These are real needs. They are also solved by hosted tools that cost a subscription and one afternoon of setup. Hosted form builders, shared calendars and spreadsheet add-ons have been tested by thousands of small teams, which is a better record than anything a first release can offer.

Custom work earns its place when the rules are tangled, the volumes are high, or several teams edit the same record and step on each other. A requirement you can state in two sentences usually has none of those traits.

Write the need as one paragraph. If a stranger could choose a product from it, you have your answer. If the paragraph names a rule that no packaged tool can express, such as slab pricing that changes by route and season, a build may still be justified.

Run a product against your twenty most frequent tasks. Book a trial, load a week of real orders or tickets, and let the person who does the work click through each one. Seventeen handled cleanly is a strong fit. Time the trial with a stopwatch on a Monday morning, when the queue is longest, and note every place where the person reaches for a separate spreadsheet.

The other three can often be met with a custom field, a saved report or a small connector. Building a whole system to cover three gaps means paying to rebuild seventeen things that already work. Ask the vendor how a customer typically bridges each gap, and ask for an introduction to someone who has done it with the same tool.

Be honest about pride. Some teams want a tailored system because it feels like theirs. That is fair, but it is not a requirement.

Software needs a keeper. Someone approves changes, answers the staff who are stuck, reads the backup report and decides when an invoice layout may change. Without that person, even good software drifts into a pile of exceptions. Typical duties include reading the monthly backup report, approving new user accounts, and deciding which of five competing change requests goes first.

If the only candidate is the owner who already covers sales, purchasing and payroll, a build adds a fourth job. A licensed product at least arrives with a vendor who patches it and a help desk. Ask whether a part-time external adviser could hold the role for a year, handing over to a trained internal person once the system settles.

Name the keeper before you name a developer. No name, no project.

Many businesses pay for accounting, CRM or spreadsheet suites with features nobody has switched on. Approval flows, custom fields, saved views, scheduled exports and webhooks sit untouched in the admin menu. Look at the renewal invoice for each subscription and ask a plain question: which of the listed modules did anyone open last quarter?

Ask the vendor’s support team to walk through the settings that match your pain, then spend a month using them properly. If the pain remains, you will hold an exact list of what is truly missing. Record the date each setting changed, so that you can compare weekly returns, order delays or ticket counts before and after.

That list is the best brief any later build could start from. It also stops you paying twice.

Sometimes a lender, a parent company or the board has already chosen the platform. Sometimes a merger is due and every process will change within the year. Building into either situation wastes effort. Check the loan covenants and the group IT policy before you spend time on options, because both can close the question in one email.

Spend the time on the process instead. Draw who does what, where the handover breaks, and which documents go missing. A clean process moves to any system later. A one-page swimlane chart, with a lane for sales, stores, accounts and dispatch, usually reveals the faulty handover within a morning.

Pick one pain, fix it on paper this month, and ask the build question again after the next quarter closes.