Point of view
Most operations problems are wearing a tech costume
Nobody calls a developer because they want software. They call because two people disagree about the same number and one of them is about to lose money over it. This is what I have learned taking the costume off.
- Written from builds, not theory
- Pune, India
The call always sounds technical
It arrives as a technology request. We need an app. We need to get off spreadsheets. Our system is old. Every one of those is a real sentence a real owner has said to me, and not one of them is the actual problem.
The actual problem is almost always the same shape. Somewhere there is a number more than one person is responsible for and nobody owns. Stock on hand. Which truck has which load. What was invoiced against what was delivered. It lives in three places, updated at three different times, and someone spends an afternoon a week reconciling it. That is not a technology failure. It is an ownership failure that software happens to be good at fixing, because software can refuse to let two people be right at once.
Which is why I watch before I scope
The first thing I do on a new build is not open an editor. It is spend time with whoever physically moves the thing. The person on the floor, the person on the phone with drivers, the person printing the challan. Not the owner, and not the person who will sign off.
They will show you the workaround, and there is always a workaround. A second spreadsheet nobody mentions in the meeting. A WhatsApp group that is really the dispatch system. A notebook. That is the requirements document, and it is the one nobody thinks to hand over.
On the textile system, the thing that mattered most was not the inventory ledger. It was printing a sticker for every roll. Nobody put that in a brief. I watched two people walk a warehouse looking for one specific roll of fabric, and that was the build.
Excel is not the enemy, and people who say it is have not run a business
Every agency deck opens by insulting the spreadsheet. That is lazy, and it is bad positioning, because the spreadsheet is often the most sophisticated thing in the building. Someone built it. It encodes years of hard-won rules about how that business actually works. It is free, it never goes down, and everyone knows how to use it.
It does exactly one thing badly, and it is the one that matters: there is no such thing as a locked row in a file that lives in four inboxes. So the honest pitch is not "replace your spreadsheets". It is keep every rule you worked out in them and put it somewhere that can enforce it. A good build is mostly transcription. The intelligence already exists.
The best sign a build will fail
It is not budget, and it is not technical difficulty. It is when nobody on the client side can give the project two hours a week.
I have lost real money learning this. One build was scoped for a month of requirements and took six, because the person who understood the domain was too busy to sit with us. We ate the overrun, because our contract never said what the client owed the project. That was my failure, not theirs.
Every engagement now states what the client owes and by when, in the same document that states what we owe. If a business cannot name someone who will answer questions inside a day, the build is not ready, whatever the budget says.
The shape of the work
Thirty days is not a marketing number. It is a forgetting number.
Past about six weeks, an operator stops being able to hold what they asked for in their head. They cannot tell whether what you are showing them is what they wanted, so they stop reviewing honestly and start nodding. By month four everyone is agreeing about something nobody remembers specifying.
Short cycles are about keeping the client able to tell you that you got it wrong while it is still cheap. I have shipped a twelve-month project where requirements moved for eight of them, and the client could not launch it anyway. Short cycles are the constraint I put on myself after that.
Three things I will argue with you about
That you need a mobile app. Usually you need a web page that works on a phone. An app is a distribution problem, an update problem and a store-review problem attached to the thing you actually wanted. Sometimes it is right. On the matrimony platform it was clearly right, because people check that kind of thing standing in a queue. For a dispatch board, it almost never is.
That you should wait until the process is tidy. It will never be tidy. The mess is the specification. If you wait to clean it up first you will spend six months producing a document describing a business that does not exist yet.
That the cheapest quote is the cheapest outcome. I say this knowing exactly how it sounds coming from someone who sells builds, so here is the version that costs me money instead: if what you need is a website, a store or a booking form, do not commission custom software for it. Buy the thing that exists. I have moved a client onto a page-builder platform at my own cost when that was the honest answer.
If any of that sounded like your operation
Find out where yours is leaking
Fifteen questions. Find out what your spreadsheets are costing you. No call, and nothing in it is a pitch.