When a business process is not working properly, it is tempting to assume the answer is more development.
A new feature.
A new plugin.
A new integration.
A new dashboard.
A new website.
A new piece of software to “just make it work”.
I understand why this happens. I have spent a large part of my career building systems, integrating platforms and helping businesses improve the technology they rely on. Development can be incredibly useful when it is solving the right problem.
But one thing I have learned over many years is this:
If the underlying business process is broken, hiring another developer usually just turns a messy process into a more expensive messy process.
Technology can improve a business process.
It can automate it.
It can speed it up.
It can make it more reliable.
But it cannot magically fix a process that nobody has properly understood, challenged or redesigned.
The problem often starts with a sensible request
Most of these situations start innocently.
A business owner or manager says something like:
“Can we get the website to send this into the stock system?”
“Can we add a button that exports this report?”
“Can we get the CRM to update the spreadsheet?”
“Can we build a small tool to copy this data across?”
“Can we automate this manual task?”
On the surface, those sound like sensible development requests.
Sometimes they are.
But often, once you look more closely, the real problem is not the missing feature. The real problem is the process around it.
The business might be using the wrong system as the source of truth. Staff may be entering the same data into three different places. A spreadsheet may have become business-critical. Two departments may be working from different assumptions. Nobody may have agreed what should happen when an order changes, a product goes out of stock, or a customer updates their details.
In that situation, building another feature may help temporarily.
But it rarely fixes the root cause.
Developers build what they are asked to build
Good developers are valuable.
But most developers are not brought in to redesign the business.
They are usually given a brief and asked to deliver against it.
If the brief says, “Build a tool that copies data from System A to Spreadsheet B,” that is what they will build.
But what if Spreadsheet B should not exist?
What if System A is not the right source of information?
What if the data is already wrong before it gets copied?
What if the real issue is that sales, operations and accounts are all using different processes?
What if the business is trying to automate a workaround that should have been removed entirely?
This is where many projects go wrong.
The developer completes the task, but the business is still frustrated because the underlying problem remains.
Automating a bad process makes the bad process faster
One of the biggest mistakes I see is businesses trying to automate too early.
Automation is powerful, but only when the process being automated is sound.
If a process is unclear, inconsistent or full of exceptions, automation can make things worse. It can move bad data faster. It can create errors at scale. It can hide problems that staff used to spot manually. It can make the business dependent on a process that was never properly designed in the first place.
I have seen businesses where staff were manually copying order information between systems. The obvious request was to automate the copying.
But once we looked at it properly, the question became:
Why is the data being copied at all?
Which system should own the order?
Which system should own the stock figure?
When should the customer be notified?
What happens if stock changes after the order is placed?
What happens if the courier rejects an address?
What happens if the order is part-shipped?
Those are not just development questions.
They are business process questions.
If you skip those questions and go straight to development, you risk building something that works technically but fails operationally.
A familiar example: the spreadsheet that became a system
I have seen this many times in owner-run businesses.
A spreadsheet starts as a quick fix.
At first, it tracks a few orders, projects, customers or stock items. Then someone adds colour coding. Then formulas. Then a few tabs. Then a pivot table. Then it becomes the place where staff check what is really happening.
Eventually, the spreadsheet becomes more important than the official systems.
At that point, someone asks for development work:
“Can we get the website to update this spreadsheet automatically?”
“Can we build a tool that imports this spreadsheet?”
“Can we make the CRM match this spreadsheet?”
Sometimes that might be useful in the short term. But often, the better question is:
Why has the spreadsheet become the most trusted system in the business?
That usually reveals a deeper issue.
Maybe the stock system is not being updated properly.
Maybe the CRM is too clumsy.
Maybe the ecommerce platform does not reflect operational reality.
Maybe staff do not trust the reports.
Maybe nobody has mapped the process from order to fulfilment to invoice.
The spreadsheet is not the root problem. It is a symptom.
Hiring a developer to support the spreadsheet may make the symptom easier to manage, but it does not necessarily fix the business.
Another example: the website blamed for an operations problem
I have also seen businesses blame the website when the real issue sits behind the scenes.
For example, an ecommerce business might say:
“The website is causing problems with orders.”
But when you look more closely, the website is only one part of the chain.
The actual issue may involve stock availability, warehouse picking, courier rules, product data, customer communication, returns, accounts or reporting.
A developer can change the website.
But if the product data is inconsistent, the stock process is unreliable, or the warehouse workflow is unclear, the same problems will keep appearing in different forms.
The website may be where the problem becomes visible.
But it may not be where the problem begins.
More software can create more complexity
Another common response to a broken process is to buy or build another system.
This is understandable. New software feels like progress.
But adding another system to an already confused process can make things worse.
Now the business has one more login, one more database, one more set of reports, one more place where customer information might differ, and one more thing that needs to be maintained.
I have worked with businesses where the real challenge was not a lack of software. It was too many tools, each solving a small part of the problem, with nobody responsible for the whole picture.
That is when businesses end up with:
- Ecommerce in one system
- Customer records in another
- Stock in a spreadsheet
- Accounts somewhere else
- Courier details in a portal
- Sales reports exported manually
- Staff using email to fill the gaps
In that situation, hiring a developer to add another tool may not be the answer.
The answer may be to simplify, integrate or redesign the way information moves through the business.
The real work starts before development
Before writing code, I usually want to understand the process.
That means asking practical questions:
- What is the business trying to achieve?
- Where does the process start and end?
- Who is involved?
- What systems are currently used?
- Where is data entered manually?
- Where do mistakes happen?
- Which system is the source of truth?
- What information does each team need?
- What exceptions happen regularly?
- What is currently slowing people down?
- What would a better process look like?
These questions are not glamorous, but they are where the value is.
Once the process is clear, development becomes much more effective.
You can then decide whether the business needs:
- A system integration
- A workflow change
- A better report
- A replacement system
- A small automation
- Staff training
- Supplier changes
- A new internal process
- Or no development at all
Sometimes the best technical decision is not to build anything yet.
A better brief saves money
One of the most expensive things a business can do is give a developer an unclear brief.
Not because developers are trying to waste money, but because unclear business thinking turns into unclear technical work.
If a process has not been properly mapped, the developer ends up discovering exceptions during the build.
Then the project expands.
Then new requirements appear.
Then staff realise the system does not handle certain real-world cases.
Then the budget increases.
Then confidence drops.
A clear process creates a better brief.
A better brief reduces waste.
It also makes it much easier to judge whether the finished work is successful.
Instead of saying, “Build us an integration,” the business can say:
“When an ecommerce order is paid, stock should be reserved immediately, the warehouse should receive the pick list, the customer should receive the correct notification, the courier label should be generated using validated address data, and accounts should receive the order information without manual re-entry.”
That is a much better starting point.
The role businesses actually need
In many growing SMEs, the missing role is not another developer.
It is someone who can sit between the business and the technology.
Someone who can understand the commercial goal, map the operational process, challenge assumptions, translate requirements and then decide what technology is actually needed.
That might be a Fractional CTO.
It might be a business systems consultant.
It might be a technically experienced operations adviser.
Whatever the title, the role is important because most owner-run businesses do not have the time or internal expertise to step back and look at the whole system.
They are busy running the business.
They need someone who can ask the right questions before anyone starts building.
Developers are still part of the solution
This is not an argument against developers.
Far from it.
Good developers are essential when the business needs something built, integrated, improved or automated.
But developers are most effective when they are working from a clear understanding of the business process.
The mistake is expecting a developer to fix a problem that has not yet been properly defined.
If the issue is strategic, operational or procedural, development alone will not solve it.
If the issue is that the business has no agreed process, no clear source of truth, inconsistent data or unclear ownership, the first job is not coding.
The first job is clarity.
Warning signs you may not need “just another developer”
You may need to review the process before commissioning more development if:
- Staff cannot agree which system is correct
- The same data is entered in more than one place
- Spreadsheets are being used to fill gaps between systems
- Every request comes with several exceptions
- Reports are built manually because systems cannot be trusted
- The current process depends on one person’s knowledge
- Developers keep asking questions nobody can answer
- Previous software projects did not solve the problem
- New tools have been added but the business still feels messy
- Staff are working around systems instead of using them properly
If these sound familiar, the issue probably sits deeper than the next development task.
What to do instead
Before hiring another developer, take a step back.
Map the process.
Identify the systems involved.
Find the duplicated work.
Decide where the source of truth should be.
Look at where errors happen.
Ask staff what slows them down.
Work out what the business needs the process to do, not just what the current workaround does.
Only then decide what should be built, integrated or automated.
This does not need to become a huge corporate exercise. For many SMEs, a practical business systems review is enough to uncover the main bottlenecks and create a sensible action plan.
The goal is not to document everything for the sake of it.
The goal is to make sure the business is solving the right problem.
Final thought
Hiring another developer can be the right decision.
But only once you understand what you are asking them to build and why.
If the process underneath is broken, unclear or overcomplicated, development may only add another layer of cost and complexity.
The best results come when business process and technology are considered together.
Fix the process first.
Then use development to support it.
That is how technology becomes a business advantage rather than another workaround.