Software or Process? It's Both - Here's Which Matters

Most operations have a process problem and a software problem at the same time, so asking “which is it?” rarely resolves anything. Ask instead which one is load-bearing. If your team has built workarounds that quietly work, the process is carrying the tool, and the tool is the constraint. If the workarounds keep breaking, the process is.

This is the read Garaxe runs before scoping anything. It is how we have told people not to build with us - and how we keep our own builds from inheriting inconsistencies that were never the software’s fault.

Why “which is it?” is usually the wrong question

The standard advice is to fix the process first, and it is good advice. It is also no longer hard to find. Of the pages we opened on this question on 24 August 2026, the strongest already went well past the slogan: one offered a pair of substitution tests - if the software were replaced with a perfect version tomorrow, would the problem go away? If the team were replaced with a perfectly trained one, would it? - plotted the answers on a two-by-two, and named the quadrant where both are broken. Another supplied three sharp questions about process clarity: do two people follow the same steps, is it clear who decides what, could a new starter follow the work without being told the unwritten parts.

That is genuinely useful, and we would rather point you at it than pretend it does not exist.

Here is where it stops. Run those tests honestly on a real operation and the answer comes back “both” - not occasionally, but most of the time. Almost every business running on software it did not design has some process drift and some tool friction. The two-by-two tells you that you are in the awkward quadrant. It does not tell you which side of it is actually holding you back, and that is the only thing that decides where the next pound goes.

The page we found that named this most clearly also declined to resolve it: it described an unclear process being carried by a tool that was never configured for the real work, and left the reader to judge which mattered more. That judgment is the whole decision.

The dominance read

When both causes are present, the question becomes: which one is currently doing the load-bearing work of holding the operation together?

Your team has already run this experiment for you. Wherever a process is unsettled and a tool does not fit, people invent workarounds - a spreadsheet beside the system, a WhatsApp thread, a naming convention someone made up. Those workarounds are not noise. They are evidence, and their behaviour over time is the signal.

What the workaround does	What is load-bearing	What that justifies
Works reliably; everyone uses it the same way; it has survived staff changes	The process is carrying the tool. People have settled the work themselves and the software is the thing that cannot hold it	A software intervention - the workaround is a specification you already paid for
Breaks whenever the person changes, volume rises, or an exception appears	The process is the constraint. The workaround is compensating for an unsettled way of working, not a missing feature	Process work first. New software would encode the inconsistency
Different people have different workarounds for the same job	The process is the constraint, and more clearly than above - there is no single way of working for any tool to support	Process work first; do not scope anything yet
No workaround exists; the pain is simply absorbed as rework	Ambiguous - usually process, occasionally low volume that never forced a decision	Watch for a month before spending. This may not be a software decision at all

The middle two rows are where most owners under spending pressure actually sit, and they are the rows that make the purchase premature.

Finding the workaround is harder than reading it, because the people using one rarely call it that. Nobody says “here is our workaround.” They say “oh, I just keep a sheet for that,” usually as an aside, and usually only when asked about a specific job rather than about the system in general. Ask what they do when the tool cannot cope, what they check before they trust a number, and what they would have to explain to a new starter that is written down nowhere.

A stable, uniform workaround is the most valuable artefact in this whole diagnosis. It is a working specification, written by the people who do the job, tested against real exceptions, and free. When we are handed one of those, scoping gets faster and cheaper, because the argument about how the work should go has already been settled in practice.

Reading the signals you already have

The dominance read is quicker if you first know which signals belong to which cause. Answer for a single workflow, not the company, and ask the person closest to the work - divergence between their answer and yours is itself data.

Signals that point at process

• The same job is done two or three ways depending on who does it.
• Exceptions have no defined path - they are figured out each time.
• Training a new hire requires shadowing rather than reading.
• Two people describe “done” differently.
• The workaround changes when the person changes.

Signals that point at software

• The work is done consistently, but the same re-typing or side spreadsheet recurs every week regardless of who does it.
• A report needs reconciliation outside the tool before anyone trusts it.
• A field, approval gate or permission the work genuinely requires does not exist and cannot be configured in.
• The vendor’s answer to “can this be configured?” is vague, or arrives as an add-on whose vocabulary does not match your work.

One further signal is worth borrowing: friction that shows up in several teams at once tends to indicate something structural rather than a local habit. Treat it as one input among these, not as a verdict.

When the answer is “both” - and it usually is

Assume from the outset that both are true and that you are sequencing, not choosing.

Process work goes first in most cases, even when the dominance read says software is load-bearing. The reason is not moral; it is that process work is reversible, cheap, and fast, and it produces the written path that any subsequent tool decision needs as its input. Two weeks of running a deliberately consistent process inside the tool you already own will isolate the remaining pain better than any amount of discussion.

The exception is the first row of the table. Where a stable, uniform workaround already exists, the process work has effectively been done - informally, but done. Making people re-derive it as a documentation exercise before you will discuss software is bureaucracy, and they will resent it. Document what they already do, and move to the tool question.

When the answer is “neither”

This is a real outcome, and it is missing from every page we read on this question.

Sometimes the work is done consistently, the tool fits well enough, and the pain you are feeling is volume, price, staffing, or a market that moved. Software is simply not the constraint, and buying some will convert a manageable problem into a project with a budget and a launch date.

We say this in intake more often than is good for our order book: there is no software decision here worth making this quarter. If that is the answer, the honest next step is to look elsewhere for gains and revisit when the volume or the business model changes.

What this read cannot tell you

It is deliberately crude, and it has limitations worth stating plainly before you lean on it. Each one below is a case where this read will mislead you.

It works on one workflow at a time. It will not diagnose an operation end to end, and it is not a substitute for process mapping where the work genuinely spans several departments.

It reads current behaviour, so a brand-new team with no workarounds yet gives it very little to go on - the fourth row of the table exists for exactly that case, and “wait” is the correct answer there.

It also cannot price anything. Knowing which cause is load-bearing tells you where to spend, not how much, and a confident number for an undescribed project is a warning sign regardless of which side of this diagnosis you land on.

Finally, it is our framing, not an established method. It comes from the intake questions we use before recommending a build, described here as we actually use them. We have no measured success rate for it, and we are not going to invent one.

What to do this week

Pick the workflow that costs the most rework. Sit with the person who does it and find the workaround - there will be one. Ask whether it survives holidays, new starters and busy weeks.

If it is stable, you have a specification, and a software conversation is justified. If it breaks, write the one-page path and run it inside your current tool for a fortnight before anyone scopes anything. If there is no workaround and no real pain, do nothing, and spend the money on something that is actually constraining you.

FAQ

We fixed the process and it still hurts - now what? Then you have isolated a real software problem. The work is consistent but the tool still fights you - fields are wrong, permissions don’t match, or reports need a side spreadsheet to be true. That is exactly when the five-type diagnosis and the six-question matrix become useful.

Can we fix process and tool at the same time? Only when the two are demonstrably independent. When the unsettled process is upstream of the tool - which it usually is - building now bakes in today’s inconsistencies as tomorrow’s constraints.

What if the vendor says the software can be configured to fix it? Ask for the specific configuration that makes the most expensive workaround disappear within two focused days. If that move doesn’t halve the pain, the problem is not configuration - it is the product’s boundary.

Our team already knows the process - is that settled enough? If training a new hire requires shadowing rather than reading a one-page path, the process is not settled for tooling purposes. Consistency across people, not senior expertise, is the test.

Notes

• Live result set retrieved 2026-08-24 (en, GB proxy) via requests req_01649526dd02 and req_6c8d995f9ce3, both at zero budget. Four pages were opened and read in full; see research/live-result-set.md. The published set converges on process-first advice, and the strongest pages supply a separation test and handle the both-are-broken case - what none of them resolves is which cause dominates.
• The dominance read, the workaround-as-evidence framing and the “neither” outcome are Garaxe’s own, drawn from the questions we use at intake. No client outcome, success rate or case result is claimed anywhere on this page.
• No AI-assistant answer baseline was collected: the probe was unavailable on 2026-08-24. Nothing here should be read as a claim about what an assistant answers for this question.
• Two audience-evidence gaps in this research: autocomplete returned no suggestions and the forum source failed to authenticate, so this page makes no claim about what owners search for or what practitioners say.