Before You Build Software, Find the Real Problem

Software is where most operational pain becomes visible.

The CRM is messy, reports take too long to pull, the intake form confuses customers, and the team has built a spreadsheet to bridge what the two systems cannot. 

When pain like this shows up, the first instinct is to fix the software. That instinct is often half right.

Sometimes the tool needs to be rebuilt. 

Other times the process behind the tool needs to be defined, the ownership of a decision needs to change, or the data model itself is wrong. 

The smartest move before any rebuild gets approved is figuring out which kind of problem you are actually solving. 

The technical, the operational, the structural, and the behavioral all show up the same way at the surface.

‍

What looks like a software problem

The list of symptoms leaders bring to us is consistent across industries. 

The specifics change but the shape of the conversation does not.

• Employees avoid the system and run their work out of spreadsheets instead.
• Reports take longer to pull than the cycle the business runs on.
• The same information lives in three places, and none of them agree.
• Teams enter the same data more than once because the systems do not talk to each other.
• Customers experience delays because the internal handoff between sales and operations is unclear.
• Managers have stopped trusting the dashboard, so they check the underlying data themselves before any standup.
• One person on the team knows how the whole process actually works, and every other person routes their questions through them.

These all show up inside software but none of them automatically mean the software is the source of your issue.

‍

What makes something a true software problem

Sometimes the tool is the problem, and the signs are specific once you know what to look for.

A true software problem looks like this:

• The tool cannot represent the workflow the business now runs. The CRM has no field for the thing the team needs to track. The workflow tool routes every approval to the same person because the system does not understand the new approval logic. The reporting layer cannot answer the question the business is asking, even with custom queries.
• The database structure no longer matches how the business operates. The schema was built when the company sold one product to one customer type. It does not handle the multi-product, multi-segment, multi-region operation the company has grown into.
• The integrations are broken or missing. The CRM does not talk to the billing system, the billing system does not talk to the data warehouse, and the data warehouse pulls from a sync that breaks every time someone upstream changes a field.
• The system was never designed for the process the team is running now. The team is using ten percent of the platform's features and writing a hundred workarounds on top of it.

BeaconMedaes came to us with that kind of problem. 

They needed a portal that would let hospital administrators see what equipment they had installed, where it was, and what its status was. Before MyMedGas, that visibility did not exist in any form the administrators could access. 

The build did one thing: it gave the operation a tool that matched what was already happening, in a form the people running it could actually use. 

That is a true software problem solved by a true software build.

‍

What makes something an operations problem

The harder cases are the ones where no software can fix what is actually broken.

An operations problem looks like this:

• Nobody owns the final approval. The workflow stalls because two people both think the other one is supposed to make the call.
• Different departments define the same field differently. Sales calls a deal "closed" when the contract is signed. Operations calls it "closed" when the customer has gone live. Finance calls it "closed" when the first payment lands. The same record means three different things to three different teams.
• The workflow changes depending on who is working that day. One account manager handles renewals one way. The other handles them differently. Both think their way is the standard.
• Leadership has not decided what the source of truth should be. Sales says the CRM is the source of truth, operations says the project tracker is, and finance says the accounting system is. The team is running on three sources of truth that disagree.
• The process exists in one person's head. They built it over years, they know the exceptions, they know the workarounds, and they have never had to write it down because they have always been there to apply it.
• The system is being asked to enforce a process the company has never fully defined.

None of these get solved by buying or building software. 

The software will reflect whatever decision the operating model has made, and when the operating model has not made a decision, the software will reflect that too.

Commonwealth Bank of Australia found this out in a very public way in 2025 when they cut 45 customer service roles, citing an AI voice bot that the company said had reduced call volumes by 2,000 a week. 

The bot was working. 

What was not working was the operating model underneath: call volumes were actually rising, team leaders were being pulled in to handle overflow, and the call queue was being held together with overtime. 

The software had absorbed some of the work. 

The operating model had been broken for longer than that. 

By August, the bank had reversed the decision and rehired the workers, with the bank admitting in writing that the redundancies had been an error.

The bot did what bots do. 

The decision to treat the bot as a substitute for fixing the operation is what produced the public reversal.

‍

The gray area: when both are true

This is the most common version we see. 

A growth-stage company hits a point where the software no longer fits and the operating model is no longer clear, and the two problems have been feeding each other for so long that it is hard to tell which started first.

A few of the patterns:

• A spreadsheet started as a temporary fix for one report. Two years later it is the system of record for that part of the business, and the team has built three more spreadsheets around it to handle the parts the first one cannot.
• A manager manually approves every request because the workflow tool does not route correctly. By the time leadership realizes the manager is the bottleneck, the team has built a side channel in Slack to get around them when something is urgent.
• Customer service has been keeping notes about each customer in a side document, because the official fields in the CRM do not capture the context the team needs. New hires are trained on the official CRM. The senior people train them on the side document later, in private.
• Reports are routinely late because the data has to be cleaned by hand before anyone trusts it. The cleanup is done by one analyst whose calendar is full of weekly cleanup meetings.

Witherspoon Rose Culture came to us with the gray-area version of this story. Spray mix tracking was still on paper, end-of-month financial close was being rebuilt by hand, and the operation had grown into a shape that ran on three people's institutional knowledge.

The systems they had bought to support it had never been redesigned to match the new operating model. 

We built Quickrose, the operations platform that runs the company now. The build was a software rebuild and an operating model rebuild at the same time. 

The two could not have been separated.

‍

A diagnostic framework

Before you approve the next software build, run the operation through these questions. 

The answers tell you what kind of problem you are actually solving.

Start with the workflow, not the tool. Map how the work actually moves from request to completion. Who initiates. Who approves. Who hands off to whom. What gets passed along with the handoff and what gets lost. If the map is fuzzy in places, those places are operations problems.

Find the repeated manual steps. Manual work is not automatically bad. Manual work the team does the same way every time, on every record, usually reveals a system gap. Manual work the team does differently every time usually reveals an operations gap.

Look for decision delays. When work stops because nobody knows who owns the next step, the issue is operational. When work stops because the system cannot route it correctly even though everyone knows who should get it, the issue is technical.

Check whether the data structure matches the business. If reports require cleanup every time, the system may not be capturing the right information in the right shape. That is a software problem. If reports require cleanup because different teams define the fields differently, that is an operations problem.

Ask who benefits from the current workaround. Workarounds survive because they give someone something. Speed, control, flexibility, plausible deniability. The reason a workaround survives tells you what the business actually values, even if leadership has not named it.

Identify what would still be broken after a rebuild. This is the sharpest question on the list. If you imagine the software is replaced tomorrow with a system that does exactly what the team has asked for, what is still broken? If the answer is "ownership," "definitions," or "approval rules," you have operations work to do before or during the software build.

‍

What to fix before building

When the diagnostic surfaces operations work, the temptation is to skip it and start the build anyway, on the assumption that the build will force the operations decisions to get made.

That assumption is expensive. The build will surface the operations questions, but it will surface them in the middle of the engagement, when the engineering team has to stop and wait for the answers, and when the cost of changing direction is higher than it would have been if the answers had been worked out beforehand.

The cleanest builds happen when the company shows up with the following already worked out:

• The actual workflow, end to end, including the exceptions that happen often enough to design for
• The owner of each decision in the workflow
• The data the workflow actually requires, with the fields defined the same way across every team that touches them
• The system of record for each piece of that data, decided in advance and not negotiated mid-build
• The integrations needed with the rest of the operation
• The reporting outcomes the leadership team will actually use

Not every project shows up with all of this clarity…

The teams that get the most out of a software build are the ones that did the honest work of figuring out what kind of problem they had before they signed a contract.

We believe that business is built on transparency and trust, and that good software is built the same way. 

The trust starts with being clear about what the software can and cannot solve. A custom build can give your operation a tool that matches how it actually runs. 

A custom build cannot decide for you who owns the approval, what the source of truth is, or whether the workflow is even the right one.

The best software projects do not start with code. They start with an honest look at how the business actually works. 

When the operating model is clear, software reduces friction, enforces consistency, and creates visibility the team did not have before. 

When the operating model is unclear, software exposes the confusion at speed.

Before you approve the next build, ask the harder question. If your software was replaced tomorrow with the version your team has been asking for, what would still be broken? 

The answer tells you where the actual work is…