Custom software can solve problems that spreadsheets, manual processes and off-the-shelf tools struggle with.
But that does not mean every inefficient process should immediately become a software project.
Sometimes the biggest opportunity comes before development starts.
At Nort Labs, we would first ask:
Which parts of the process are repetitive, predictable and already understood well enough to automate?
That question matters because building software around a bad process does not automatically improve the process.
It can simply make the bad process happen faster.
Start With the Process, Not the Software
Imagine a business wants a new internal system because staff are spending too much time managing customer enquiries.
The immediate reaction might be:
We need a custom CRM.
Maybe they do.
But before deciding that, it is worth understanding what people are actually doing.
For example:
- Where do enquiries arrive?
- Who records them?
- What information gets copied manually?
- Who decides what happens next?
- Which steps are repeated every time?
- Where do delays normally happen?
Once the process is visible, some problems may turn out to be much simpler than they first appeared.
The software decision becomes easier when you understand exactly what work the software needs to remove.
Automate Repetitive Data Entry First
Repeatedly entering the same information is one of the clearest automation opportunities.
A customer might submit a website form.
Someone then copies the details into a spreadsheet.
Another person enters them into a CRM.
Finance later copies part of the same information into another system.
None of those jobs may feel significant individually.
Together, they create wasted time and more opportunities for errors.
If information already exists digitally, ask whether it really needs to be typed again.
Often, systems can pass information between each other automatically.
That might mean:
- website enquiries going directly into a CRM
- orders creating records automatically
- customer details feeding into another internal system
- completed forms triggering the next workflow step
This kind of automation can sometimes remove a surprising amount of manual work without requiring an entirely new software platform.
Automate Notifications and Reminders
A lot of business processes depend on somebody remembering to do something.
For example:
- follow up an enquiry
- send a customer update
- chase an approval
- renew a document
- check an overdue job
- send an appointment reminder
These tasks are important, but they are often predictable.
If the rule is:
When X happens, remind person Y after two days
that is a strong candidate for automation.
The advantage is not simply speed.
It reduces the number of routine tasks that rely on somebody remembering them at the right moment.
Automate Simple Status Changes
Many internal processes have predictable stages.
An enquiry becomes qualified.
A quote becomes approved.
A project becomes active.
An order becomes dispatched.
A job becomes complete.
If somebody is manually updating several systems every time one of those stages changes, automation may be possible.
For example:
When a quote is approved → create the project → notify the relevant team → update the customer record.
That is much easier to automate than a process requiring subjective judgement at every step.
The more clearly defined the transition, the stronger the automation opportunity.
Look for Rules People Apply Over and Over Again
Another useful question is:
What decisions are staff repeatedly making using the same rules?
For example:
- assigning enquiries based on location
- routing support requests based on category
- flagging invoices after a certain period
- allocating jobs based on availability
- sending different information depending on a customer’s selection
If a decision can be described consistently, software may be able to handle at least part of it.
If every situation is completely different and requires significant judgement, full automation may be less appropriate.
This distinction matters.
Not everything that takes time should be automated.
Do Not Automate a Process Nobody Understands
This is one of the biggest risks.
A process may be frustrating because it has never been properly defined.
Different employees may perform the same job differently.
Exceptions may exist that nobody has documented.
Important decisions may live entirely in one person’s head.
Building software at that stage can lock unclear behaviour into the new system.
Before automating, document what actually happens.
That does not require a hundred-page specification.
It may simply mean mapping:
- how the process starts
- what information is required
- who is responsible
- which decisions are made
- what exceptions exist
- what defines completion
If nobody can agree on the process, the first problem may not be software.
Do Not Automate Rare Problems Just Because They Are Annoying
Some tasks are frustrating but happen twice a year.
Automating them may take more effort than simply continuing to handle them manually.
Frequency matters.
A task performed ten times a day is very different from something that happens once every six months.
When prioritising automation, look at:
- how often the task occurs
- how much time it takes
- how often mistakes happen
- how expensive those mistakes are
- how predictable the task is
A boring five-minute job performed hundreds of times can be a much better automation target than a complicated hour-long job performed occasionally.
Use Existing Integrations Where They Already Solve the Problem
Custom development is not always necessary.
Many existing business tools already support integrations, automation rules, APIs and workflow features.
Before building a bespoke solution, check whether the tools already being used can communicate with each other.
For example, a business may already be able to connect:
- website forms
- CRM software
- email platforms
- accounting systems
- project management tools
- booking systems
If an existing integration reliably solves the problem, using it can be faster and cheaper than rebuilding the same functionality.
Custom software becomes more valuable when existing tools cannot represent how the business genuinely needs to work.
Where AI Fits In
Not every automation needs artificial intelligence.
This is an important distinction.
If the rule is straightforward:
When a form is submitted, create a record.
You do not need AI.
Traditional automation is usually the better fit.
AI becomes more interesting when the input is less structured.
For example:
- classifying incoming messages
- extracting information from documents
- summarising long text
- drafting responses
- interpreting natural-language requests
Even then, the decision should be based on whether AI genuinely improves the process.
At Nort Labs, we would not add AI simply because the project involves automation.
Use deterministic software where the rule is deterministic.
Use AI where variability in the input makes traditional rules impractical and where the risk of incorrect output can be managed appropriately.
Automate the Stable Parts Before the Complicated Parts
A useful approach is to divide the process into two groups.
Stable steps
These happen in roughly the same way every time.
Judgement steps
These require somebody to interpret information, make a decision or deal with an unusual situation.
Automate the stable steps first.
For example:
A sales enquiry process might involve:
- receiving the enquiry
- recording customer details
- checking the enquiry
- deciding whether it is a good fit
- assigning it to somebody
- sending confirmation
Recording the details and sending confirmation may be easy to automate.
Deciding whether a complicated project is commercially suitable may still require a person.
That is completely fine.
Good automation does not need to remove humans from every step.
When Custom Software Starts to Make Sense
Once the obvious automation opportunities are understood, you may discover that the remaining problem is bigger.
Perhaps the business still relies on several disconnected tools.
Maybe important information is scattered across different systems.
Maybe the team has developed increasingly complex workarounds.
Maybe existing software simply does not match the workflow.
That is when bespoke software becomes more interesting.
Nort has previously looked at custom software for small businesses and when businesses may prefer custom CRM software.
The important difference is that the software project now has a much clearer purpose.
Instead of:
“We need new software.”
you can say:
“We need to remove these five manual steps, connect these systems and give these people one place to manage the process.”
That is a much stronger starting point for development.
Do Not Build Software Around Every Existing Habit
There is another trap.
When businesses replace a manual system, they sometimes try to reproduce every existing step exactly.
But some of those steps only exist because of the old tools.
For example, staff may export a spreadsheet every Friday because the current system cannot produce the report they need.
The new software does not necessarily need an “export spreadsheet every Friday” feature.
It might simply show the information directly.
Custom software should improve the workflow, not faithfully recreate every workaround in the old one.
That is why reviewing the process before development is so important.
So, What Should You Automate Before Building Custom Software?
Start with the repetitive, predictable parts of the business.
Look for:
- duplicate data entry
- manual notifications
- routine status updates
- simple rule-based decisions
- information being copied between systems
- recurring administrative tasks
Then ask whether those problems can already be solved using the tools you have.
If they can, automate them first.
If they cannot — or if you discover that the business is being held together by several disconnected systems and workarounds — then custom software may be the right next step.
At Nort Labs, we would rather understand and simplify a process before building technology around it.
The best custom software projects usually start with a clearly understood business problem, not with a list of features.
Automate what is obvious.
Keep human judgement where it matters.
Then build custom software for the parts that genuinely need something better.
