Building software around how work already happens

Most businesses already have software. It just does not look like software.

The work lives in spreadsheets, chat threads, inboxes, and a few tools that were never designed to talk to each other. People copy data between them. Status lives in someone’s head. The process works, until the volume grows or the person who remembers the exceptions is away.

When that happens, the tempting move is to buy a generic platform and force the business into it. Sometimes that is the right call. Often it just relocates the mess.

Start from the current process

On a custom operations platform I built around existing work, the problem was not a missing landing page. Operational work was spread across disconnected tools, which made everyday work harder to track. The software had to be designed around those workflows — planning, architecture, and implementation included — rather than dropped in as a template with the company name on it.

That is slower at the beginning. You have to ask how work actually moves, where it gets stuck, and which exceptions are load-bearing. It is faster than building the wrong system and spending the next year on workarounds.

The same pattern showed up in a WhatsApp lead-capture workflow. The communication channel already existed. Leads were already arriving there. The useful software was a workflow around that channel, not a new place for people to remember to look.

Custom does not mean “rebuild everything”

Custom software is easy to oversell. I do not think every spreadsheet needs to become a platform.

I look for a narrower question: which parts of the work are painful enough, repeated enough, or shared enough that software would make them clearer?

That might be a single operational workflow. It might be a way to capture incoming requests so they stop disappearing. It might be a first version of a product that later grows into something larger. It is rarely “replace the entire company operating system in one pass.”

The process I use is built for that kind of scoping: understand the current work, define a useful slice, build it, then learn from real use.

What I try not to do

I try not to start coding before the workflow is clear. I try not to recommend a tool because it is popular. I try not to pretend that a generic product will become specific if we change the colors.

If the off-the-shelf option already fits, I would rather say so. If it does not, the job is to build around the work that already exists — and leave room for that work to change.

If that is the kind of problem you are sitting with, the custom software page is the closest description of the work. If you want to talk through a specific workflow, start a project.