The point at which a business needs software
It is rarely a decision. It is a series of small failures that start costing real money.
A part number mistyped in a WhatsApp thread becomes a wrong shipment three weeks later. Nobody can answer 'where is my order' without scrolling back through a conversation. Stock lives in one person's head, so a salesperson quoting a customer is guessing. The warehouse learns about a sale after the fact. Two teams keep separate numbers and the numbers disagree, and reconciling them is somebody's whole Friday.
Asha Schiffli Parts, an industrial exporter with a catalogue in the thousands, was running exactly this way. Customers ordered by part number and expected a date; orders arrived as chat messages. The failure mode was not carelessness — it was that a conversation is not a system of record.
How we approach it
Custom software development goes wrong when it starts from the software. We start from the process, and the first deliverable is not code.
- Process discovery — how the work is genuinely done today, including the workarounds, because the workarounds are usually where the real requirements are hiding.
- A system of record — one place the catalogue or the inventory truly lives, with everything else hanging off it: the order, the production run, the dispatch, the stock movement.
- Views built for their users. A shop floor does not want a shrunk-down admin panel; a salesperson in front of a customer does not want a reporting screen.
- Access controlled by the people who own the relationship. Pricing and order history are per-customer in most B2B businesses, so accounts get issued by the sales team rather than opened by anyone who finds the URL.
- Reporting that answers the questions the chat threads used to — pending quantities, delayed jobs, machine load, what is ready to dispatch.
Make the queue visible and the arguments stop
The highest-value feature in most operational systems is not a feature. It is that the pipeline becomes visible to everyone at once.
For Asha that meant four stages — new request, in production, ready to dispatch, dispatched — that every order moves through where anyone can see it, plus an attention queue that surfaces pending quantities, delayed jobs and machine overload before a customer has to ask. Machine-floor monitoring covers per-machine load, utilisation and OEE.
Once the state of the work is visible, most of the internal chasing disappears, because the question that prompted it has already been answered on a screen.
Progressive web apps, when the work happens away from a desk
A significant share of the software we build is used standing up — on a warehouse floor, in front of a customer, beside a machine. That rules out anything that assumes a laptop and a good connection.
For GlitterOn, a lighting manufacturer whose stock and sales lived in separate disagreeing places, we built a progressive web app: it installs on the phone already in the user's hand, survives a bad signal in a warehouse, and updates without an app store review. One stock ledger, written once, read by both inventory and sales — two views of the same data rather than two systems that reconcile later.
PWA development is the right answer more often than a native app for internal tools. No store approval, no separate builds, no asking staff to install something from a listing — and the same codebase serves the desk and the floor.
What this is not
We are a small studio, and there is work we should not take. A system requiring a dedicated support team, a twenty-person rollout, regulated data handling, or integration with an ERP we have never seen is not a fit — and finding that out in month four is expensive for both of us.
What fits: a business between fifteen and a few hundred people, an operational process that is well understood by the people doing it, and someone on your side who can make decisions. Under those conditions custom software pays for itself quickly, because the thing it replaces was costing more than anyone had counted.