Inside this week at FIWB Solutions: why custom software projects start by finding the workflow that breaks first, not the one that looks worst.
by FIWB Solutions
A client call this week started the way most of ours do. Not with a request for a new feature, but with a complaint about a spreadsheet. Someone on their ops team had built it years ago to track shipments, and now three people update it by hand, in three different tabs, and nobody fully trusts the numbers by Friday.
That is the real starting point for almost every custom software engagement we take on. Not "we want an app." It is "this thing we rely on is quietly falling apart, and we don't know which part to fix first."
When a business owner tells us their process is held together with spreadsheets, email threads, and someone's memory, the instinct is to replace the spreadsheet. That's usually the wrong first move.
The spreadsheet is a symptom. The real problem is that three or four systems, maybe an order platform, a carrier portal, a messaging app, don't talk to each other, so a person has become the integration layer. That person is doing manual data entry and calling it "coordination."
This week, the question we asked more than any other was simple: if this person went on vacation for two weeks, what would break first? The answer tells you where to start. It's rarely the part that looks the most outdated. It's the part where one delay cascades into five others, the dispatch board that three other teams check before they move, the status field that triggers a customer email.
That's the workflow worth automating first, because fixing it buys back the most time and removes the most risk, not because it's the easiest build.
We spent part of this week mapping that exact chain for a logistics client: order comes in, gets manually checked against carrier availability, gets manually re-entered into a tracking sheet, gets manually summarized for the customer. Four manual steps, one source of truth that lives in someone's head.
The fix isn't a single app. It's custom software that sits between the systems already in place, pulls the data automatically, and only asks a human to step in when something actually needs a judgment call. That's the difference between automation that removes real friction and automation that just moves the spreadsheet into a prettier interface.
A few signs a workflow is ready for this kind of fix:
If two or three of those are true for a process in your business right now, it's a strong candidate, not because automation is trendy, but because the cost of the current version is compounding quietly every week.
It's tempting, once you've mapped a workflow like this, to automate all of it at once. That's usually a mistake. Some of those manual steps exist because a person is making a judgment call that genuinely requires context: a pricing exception, a relationship with a specific carrier, a read on whether a customer's request is urgent or routine.
The work is separating the steps that are pure data movement, copying a number from one system to another, from the steps that are actually decisions. The first category is where custom software earns its keep immediately. The second category usually stays with a person, at least at first, with better information in front of them instead of a spreadsheet they have to maintain themselves.
Getting that split wrong in either direction causes problems. Automate too little and you've just added a new tool to babysit alongside the old process. Automate too much, including the judgment calls, and you lose the flexibility that made the process work in the first place, then spend months building exception handling for cases a human would have caught instantly.
This is also where a lot of off-the-shelf software falls short for operations-heavy businesses. A generic platform forces every judgment call into a dropdown menu or doesn't support the exception at all. Custom software can be built around the actual shape of the decision, not a vendor's idea of what every business in your industry needs.
Most businesses don't need an audit of everything they do. They need someone to look at the one workflow that's actually bleeding time and ask what breaks first if nothing changes. That question is usually more useful than a list of features.
If you've got a process like the one above, one that works, barely, because someone is holding it together by hand, that's worth a conversation before it becomes a bigger problem. Reply to this post or reach out through fiwbsolutions.com to talk through what you're dealing with.